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

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

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.

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

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