snellspace.com

Ok, so it’s been about a month I guess since I started talking about scripting exploits in feeds. I put together a whole bunch of Atom test cases based on an initial set of RSS tests produced by James Holderness. Several Feed Reader developers took those tests and plugged holes in their implementations. Now that implementors have had plenty of time to review the tests and check to see if they’re vulnerable, it’s time to start talking a bit about what those specific vulnerabilities are.

The suite of tests I put together can be found at the following URLs.

• http://www.snellspace.com/public/everything.atom
• http://www.snellspace.com/public/everything2.atom
• http://www.snellspace.com/public/everything3.atom
• http://www.snellspace.com/public/everything4.atom
• http://www.snellspace.com/public/everything5.atom

The first thing that you should notice when looking at these is that the overwhelming majority are based on well-known XSS exploits. For instance, Test #2 of everything.atom uses the simple trick of introducing line breaks and extra characters in script elements to fool sanitation filters.

  <entry>
    <title>2. Obfuscated script</title>
    <id>http://www.snellspace.com/public/everything.atom#2</id>
    <link href="http://www.snellspace.com/public/everything.atom#2" />
    <content type="html">&lt;script	

	x	&gt;

window.alert('Security Test #2')

&lt;/script	

	x	&gt;</content>
    <updated>2006-08-09T12:12:12Z</updated>
  </entry>

This simple technique was able to fool many Feed Readers regardless of whether or not the atom:content element was marked as type=”html”, type=”xhtml” or type=”text”… which brings up the next problem I found.

Many feed readers fail to properly handle <content type=”text”>…</content> and <title type=”text”>…</title>. The specification says that characters such as “<” and “&” in type=”text” elements MUST NOT be treated as markup. Feed Readers are required to interpret <content type=”text”>&lt;b&gt;Foo&lt;/b&gt;</content> as the literal string “<b>Foo</b>” and not as escaped markup for “Foo“. If Feed Readers would simply treat plain text elements as plain text, many of the security vulnerabilities would go away.

Consider Test 10 of everything5.atom, for instance:

  <entry>
    <title>10. atom:author with script name</title>
    <id>http://www.snellspace.com/public/everything5.atom#10</id>
    <link href="http://www.snellspace.com/public/everything5.atom#10"/>
    <content>blank</content>
    <updated>2006-08-09T12:12:12Z</updated>
    <author><name>&lt;script&gt;alert('Security Alert #10');&lt;/script&gt;</name></author>
  </entry>

The Atom specification defines the author/name element as being plain text, not markup. Implementations that inappropriately treat the value of the name element as markup will be vulnerable to the XSS attack. Surprising, there are actually quite a few readers that do so.

Also consider Test #6 of everything5.atom:

  <entry>
    <title>6. atom:category with script term</title>
    <id>http://www.snellspace.com/public/everything5.atom#6</id>
    <link href="http://www.snellspace.com/public/everything5.atom#6"/>
    <category term="&lt;script&gt;alert('Security Test #6');&lt;/script&gt;"/>
    <content>blank</content>
    <updated>2006-08-09T12:12:12Z</updated>
  </entry>

Some feed readers will take the value of the category term and will drop it directly into a browser view as markup without sanitizing the value. The term attribute is defined as being plain text.

As a general rule, implementations need to properly support the difference between plain text and markup and be careful to look for XSS exploits anywhere text or URIs can be included in a feed. These include elements such as atom:title, atom:rights, atom:subtitle, atom:summary, atom:content, atom:link, atom:category, atom:icon, atom:logo, atom:author, atom:generator, atom:contributor, etc.

The xml:base attribute is another interesting way of injecting script into a feed. Consider, for instance, the feed-level alternate link of everything5.atom:

  <link xml:base="javascript:alert('alternate_link_test')//" href="" />

Implementations that are not careful to scan for unsafe URI schemes in xml:base will end up resolving the relative href attribute reference against the javascript URI.

Another way of screwing with folks is to use doctype declarations to redefine standard HTML entities as shown in everything5.atom:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE feed [
<!ENTITY pwned "javascript:alert('Security Test #31')">
<!ENTITY nbsp "<script>javascript:alert('Security Test #32')</script>">
<!ENTITY raquo SYSTEM "http://www.snellspace.com/public/33.html">
]>
...
  <entry>
    <title>32. Redeclared DTD Entity</title>
    <id>http://www.snellspace.com/public/everything5.atom#32</id>
    <updated>2006-08-09T12:12:12Z</updated>
    <link href="http://www.snellspace.com/public/everything5.atom#32"/>
    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">&nbsp;</div></content>
  </entry>

Parsers that allow doctype entity declarations will expand the “&nbsp;” entity in the content element into “<script>javascript:alert(’Security Test #32′)</script>” rather than the standard non-breaking space.

In my testing I tried a number of techniques that would allow me to target specific individual feed readers. Based on the User-Agent header sent with most feed requests, I was able to inject script exploits against specific feed readers that would not show up in other agents. That is, you could load a feed in Feed Demon and see a XSS exploit but load that same feed in Firefox or IE to view the source and the exploit would not be there, making it very difficult to actually spot the problem.

Further, some feed readers (e.g. FeedDemon, RSS Bandit, etc) that incorporate browser-widgets in their UI to display entries use implementation specific URI schemes to inject functionality into the browser view. The “fdaction” URI scheme provides direct access to a variety of Feed Demon functions, such as toggling an entries read status, triggering the subscribe/unsubscribe dialogs, deleting entries or subscriptions, prompting users to bookmark links on del.icio.us, etc. If a malicious script does get through the sanitation filter, it is possible for those script to use the fdaction URI scheme to seriously annoy users.

It needs to be pointed out that these issues are not limited to Atom. The XSS exploits tested in my suite came originally from a set of RSS tests.

Update: It should be noted that a Feed Demon update has been released that resolves all of the issues uncovered by these tests. Many kudos to Nick Bradbury for the swift attention to these issue.

This entry was posted on Thursday, September 7th, 2006 at 9:39 amand is filed under Technology, Atom 1.0.
You can follow any responses to this entry through the Atom Comments feed. Responses are currently closed, but you can trackback from your own site.