Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

RSS and Web Feeds a Risk? 94

Posted by ScuttleMonkey 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."
This discussion has been archived. No new comments can be posted.

RSS and Web Feeds a Risk? More

RSS and Web Feeds a Risk?

Comments Filter:

  • Huh? (Score:5, Insightful)

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

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

      by Anonymous Coward
      Thread over. :)

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

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

      by StormReaver ( 59959 )
      "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
        • 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???

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

      by AVryhof ( 142320 ) <amos@NospaM.vryhofresearch.com> on Sunday August 06, 2006 @10: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
          • Simple is good, because it's not complex.
            Occam's razor. Good point.

          • "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 treat

          • 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

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

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

      by sporkmonger ( 922923 )
      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:1)

      by nxt ( 679989 )
      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....

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

    by fosterNutrition ( 953798 ) on Sunday August 06, 2006 @07: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 @08: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 @09: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 @07: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.

    • So..Carry and cash. (Score:1, Funny)

      by Anonymous Coward
      "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.

    • Re:So.. (Score:5, Funny)

      by truthsearch ( 249536 ) on Sunday August 06, 2006 @09:00PM (#15856979) Homepage Journal
      That's a bad analogy. The internet's more like a series of tubes than a truck... oh, um, forget it.
    • 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.

    • Re:So.. (Score:2, Insightful)

      by Zelbinian ( 992687 )
      Someone wiser than I once said "Common sense is not that common."

  • Bloglines (Score:3, Informative)

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

  • What sensible feed aggregator allows javascript? (Score:3, Insightful)

    by jZnat ( 793348 ) * on Sunday August 06, 2006 @08:27PM (#15856898) Homepage Journal
    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).
          • 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.

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

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

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

    by fractalVisionz ( 989785 ) on Sunday August 06, 2006 @09:11PM (#15857011) Homepage
    Never let input go unchecked. If you do, you are already screwed.

  • You're missing the point - it's about the "reader" (Score:3, Insightful)

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

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

    by Zaphod2016 ( 971897 ) on Sunday August 06, 2006 @11: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.
    • 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
      • 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 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.

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

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

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close