UPDATE: On inspecting the code it seems that my assertions in this post are incorrect. The change we made in the last release was not to enable Javascript by default. Instead it was to always ignore the Javascript setting chosen by the user for the newspaper view. This means that the current release of RSS Bandit is vulnerable to the majority of the flaws outlined in article linked below. I'll work on getting a release out that addresses this issue as soon as I can although this is complicated by the fact that we may not have a snapshot for the last release AND the first half of this week is very busy for me at work. If this security issue is a serious concern to you, my advice is to not use RSS Bandit until a release that addresses this issues is released or to switch to v1.3.0.29 of RSS Bandit which does honor the specified Security restrictions for the newspaper view.

A number of people have either sent me email or posted on the RSS Bandit forums asking whether RSS Bandit is vulnerable to the various issues raised in the article Blog feeds may carry security risk which states

LAS VEGAS--Reading blogs via popular RSS or Atom feeds may expose computer users to hacker attacks, a security expert warns.

Attackers could insert malicious JavaScript in content that is transferred to subscribers of data feeds that use the popular RSS (Really Simple Syndication) or Atom formats, Bob Auger, a security engineer with Web security company SPI Dynamics, said Thursday in a presentation at the Black Hat security event here.
"A large percentage of the readers I tested had some kind of an issue," he said. In his presentation, Auger listed Bloglines, RSS Reader, RSS Owl, Feed Demon, and Sharp Reader as vulnerable.

As protection, people could switch to a nonvulnerable reader. Also, feed publishers could ensure that their feeds don't include malicious JavaScript or any script at all, Auger said. Some services, however, rely on JavaScript to deliver ads in feeds, he noted.

To prevent this sorts of issues RSS Bandit allows users to optionally disable the running of Javascript, ActiveX or Java code in its Options dialog. Up until the last release we disabled Javascript, ActiveX and Java by default. However in the last release, we switched on Javascript by default to enable a particular features (i.e. specifically when you click on the envelope or flag on an item in the newspaper view to change the read or flagged state of an item). This means that by default RSS Bandit is vulnerable to the Javascript related issues mentioned in this article.

How to change this state of affairs is mentioned in the section of our user documentation entitled Changing the web browser security settings which has a screenshot of the Web Browser tab of the Options dialog where browser security restrictions can be set. 

Our users should configure the options to what best eases their security concerns. I'm still debating on what we need to do here in the long term but one thing I doubt we'll do is striping potentially malicious HTML tags since this seems to be a sledgehammer-like approach which may strip valid markup (e.g. <style> tags) from content. It's more likely that I'll remove our features that require enabling Javascript by default than go that route. I'd appreciate thoughts from our users on this.

Update: I was one of the developers contacted by James Snell and have failed to get back to him since I haven't gone through all of the tests he sent me yet.


Sunday, August 20, 2006 8:31:40 PM (GMT Daylight Time, UTC+01:00)
I've developed a set of checks that will allow through most common non-malicious usage of the style attributes:

Monday, August 21, 2006 12:17:05 AM (GMT Daylight Time, UTC+01:00)
FYI when I ran my tests I had that Javascript option unchecked and it still let through all the scripts. I was using version on Windows XP SP2. I've tested with IE6 and 7 and they both fail although I think IE7 let through a couple less.
Monday, August 21, 2006 2:34:36 AM (GMT Daylight Time, UTC+01:00)
Are you running the same tests as James Snell or a different set of tests. Either way, I'd like to find out what tests were getting through since it either means that our code is buggy or [however unlikely] that the IE Web control setting to disable scripts doesn't actually work.
Monday, August 21, 2006 4:46:15 AM (GMT Daylight Time, UTC+01:00)

If you are using ambient properties to disable JavaScript, there are limitations as to when ambient properties are read (during initialization, on ambient property notification event).

Since ambient properties are owned by containers, there is no way for the browser to detect when ambient property changes unless the container fires an ambient property change event. Another gotcha is that I think changes to ambient properties can't be reliably made while a web page is being loaded.
Monday, August 21, 2006 9:22:07 AM (GMT Daylight Time, UTC+01:00)

I use bloglines to read feeds, because of the whole synch issue reading from multiple machines etc, but I did play with RSS Bandit and found it to be my prefered thick client.

I also write the Syndication platform for the geeklog CMS.

My personal take on this is that HTML whitelisting is the best way to go. I would /prefer/ the majority of style to be stripped from a page. I'm interested in reading the content, that's one of the reasons I use an RSS reader, it strips the style/display etc of the site from my articles so I'm just reading the content.

There are exceptions, but not many, hence whitelisting. I tend towards pre, blockquote, code, i, b, strong, emphasis etc. Simple formatting.

The style tag and style attribute can actually be an XSS hole, you can perform pretty nasty attacks using it, you have to filter the content of the attribute/tag for behavior and javascript etc.

background-image and various other things also accept url()
arguments, which can be an issue.

Most items can have an "expression" value which is a javascript container.

The big news on CSS was the MySpace worm, which was pretty nasty:


See Also:
Monday, August 21, 2006 11:23:38 AM (GMT Daylight Time, UTC+01:00)
Dare, as far as I know, James' tests were based on my RSS test feed only he is testing Atom rather than RSS. He obviously added a lot more tests, but I'm fairly sure that everything I was testing is covered by his feeds too.

As for the IE web control settings, it surprised me that that option didn't seem to work with RSS Bandit since FeedExplorer (which I assume is based on your code) has the same kind of setting and it works for them.
Monday, August 21, 2006 2:15:20 PM (GMT Daylight Time, UTC+01:00)
An example feed where style is important:

Monday, August 21, 2006 4:23:12 PM (GMT Daylight Time, UTC+01:00)

I started by porting James H's RSS tests over to Atom, then expanded them to cover all of the areas in Atom where folks can put HTML and XHTML (e.g. title, subtitle, summary, rights, etc) as well as places that typically aren't supposed to accept script so readers tend not to look for it (e.g. author/name, category/term, category/label, etc). I've found that quite a few readers display the author name and category term without any filtering, making it a simple vector for injecting script. I also added a few tests that check for script injection using URL-based attributes and elements (e.g. xml:base, link/@href, atom:icon, atom:logo, etc).
Monday, August 21, 2006 6:07:56 PM (GMT Daylight Time, UTC+01:00)
I've updated my post. It seems we are ignoring that setting for the newspaper view but not for new browser tabs.
Comments are closed.