RSS and Web Feeds a Risk?

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

Comments

Huh?

[Umbral Blot]

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

Re:Huh?

[AVryhof]

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.

Re:Huh?

[sporkmonger]

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.

Re:Huh?

[Sepodati]

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

Old technique, new medium

[fosterNutrition]

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

[Bogtha]

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

Re:Old technique, new medium

[darkewolf]

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

[Tracer_Bullet82]

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.

Re:So..

[truthsearch]

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

Bloglines

[TheOtherChimeraTwin]

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!

Heh

[Andrew Kismet]

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

They saw it coming!

[bruno.fatia]

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

The slides can be found here

[Anonymous Coward]

RSS Security Slides

Validation is the only problem

[DivineOmega]

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.

Simple rule for input

[fractalVisionz]

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

You're missing the point - it's about the "reader"

[hutchike]

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

[The MAZZTer]

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

Re:RSS Feed: Jews are the enemy!

[Anonymous Coward]

You were awesome in Braveheart.

Bogus

[Nijika]

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

Color me stupid...

[Zaphod2016]

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