Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

RSS and Web Feeds a Risk?

Posted by ScuttleMonkey on Sun Aug 06, 2006 06:48 PM
from the risk-around-every-cyber-corner dept.
Security The Internet
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

RSS and Web Feeds a Risk? 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Huh? (Score:5, Insightful)

    by Umbral Blot (737704) on Sunday August 06 2006, @06:53PM (#15856803) Homepage
    Seems more like a problem with allowing javascript in comments (a really dumb idea) than a problem with RSS.
    • "Seems more like a problem with allowing javascript...."

      You could have stopped here, and have been even more correct.
      • +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! - alr

    • Re:Huh? (Score:4, Informative)

      by AVryhof (142320) <avryhof@NosPAM.gawab.com> on Sunday August 06 2006, @09:18PM (#15857157) Homepage
      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.

      • 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. [slashdot.org]

        • 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 pr

      • Re:Huh? (Score:3, Interesting)

        by Sepodati (746220)
        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 st

      • Re:Huh? (Score:2, Interesting)

        by Sepodati (746220)
        strip_tags() is one of the most worthless functions PHP offers. First, it gets rid of evil, nasty, harmfull code such as <grin> or <anything f'n thing>. 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>
    • 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
    • ... 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.
    • 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.

      • Re:Huh? (Score:3, Insightful)

        by Richy_T (111409)
        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

  • Old technique, new medium (Score:5, Insightful)

    by fosterNutrition (953798) on Sunday August 06 2006, @06:56PM (#15856810) Journal
    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...

    • Re:Old technique, new medium (Score:5, Informative)

      by Bogtha (906264) on Sunday August 06 2006, @07:38PM (#15856930)

      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 [diveintomark.org] 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".

      • Re:Old technique, new medium (Score:5, Interesting)

        by darkewolf (24563) <draoidh@iinet.net.au> on Sunday August 06 2006, @08:01PM (#15856983) Homepage Journal
        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

  • So.. (Score:5, Insightful)

    by Tracer_Bullet82 (766262) on Sunday August 06 2006, @06:59PM (#15856819)
    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.

  • Bloglines (Score:3, Informative)

    by TheOtherChimeraTwin (697085) on Sunday August 06 2006, @07:08PM (#15856846)
    It turns out that Bloglines [bloglines.com] 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!

  • Heh (Score:5, Funny)

    by Andrew Kismet (955764) on Sunday August 06 2006, @07:18PM (#15856869)
    Isn't it amusing I found this article by using /.'s own RSS fee!"$%&() ****NO CARRIER****
  • 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.

    • 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

      • 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".
        • 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).

  • They saw it coming! (Score:3, Insightful)

    by bruno.fatia (989391) on Sunday August 06 2006, @07:27PM (#15856899)
    If I can remote execute code, I can remote execute malicious code. Nothing new please move along
  • 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.

  • The slides can be found here (Score:3, Informative)

    by Anonymous Coward on Sunday August 06 2006, @07:30PM (#15856906)

    RSS Security Slides [cgisecurity.com]
  • 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.

  • Validation is the only problem (Score:3, Insightful)

    by DivineOmega (975982) * <jordan@hall05.co.uk> on Sunday August 06 2006, @07:42PM (#15856944)

    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.

    • I've placed RSS feeds in Opera 9.01 (Build 400) and in Mozilla Firefox 1.5.0.6 in my knoppix remaster. [geocities.com] 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 [blogspot.com]

  • Simple rule for input (Score:4, Insightful)

    by fractalVisionz (989785) on Sunday August 06 2006, @08:11PM (#15857011) Homepage
    Never let input go unchecked. If you do, you are already screwed.
  • 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 ;-)

  • Oh God (Score:5, Insightful)

    by The MAZZTer (911996) <megazzt@g[ ]l.com ['mai' in gap]> on Sunday August 06 2006, @08:40PM (#15857068) Homepage

    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"); }.

  • Bogus (Score:5, Funny)

    by Nijika (525558) on Sunday August 06 2006, @10:02PM (#15857272) Homepage Journal
    NEWSFLASH: Hackers MAY set up websites and services to lure victims! Film at 11.
  • 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.

  • Color me stupid... (Score:5, Interesting)

    by Zaphod2016 (971897) on Sunday August 06 2006, @10:16PM (#15857311) Homepage
    ...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.
      • 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".

  • "A lot of blogs will take user comments and stick them into their own RSS feeds," he said.

    Blogger [blogger.com] 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 [editthis.info]), check out this bloghacking wiki [editthis.info].

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

    -Thetan.

  • 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
  • World to end unless you buy stuff from the authors [spidynamics.com]

    Just predicting next week's USA Today exclusive.
    • 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 def

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.