More on Feed Security

  • Article

Shortly after the SPI Dynamics presentation that sparked a renewed discussion on feed security in the community last month, James Snell developed a suite of tests (based on an earlier set by James Holderness), and generously made them available quietly to aggregator developers. He has now made the tests public.

I contacted James last month (via email as he requested) and he pointed me to the test suite, so we could test them against our own security mitigations. We have done full test passes using his test suite.

The result:IE7 passed all of the tests(which means that no script from the feeds executed successfully in IE, and that developers using the RSS platform would not have been vulnerable to the class of attacks in the tests). This confirms SPI Dynamic's findings that IE7 was not vulnerable to the attacks described in their paper.

I thought it might be useful to use this opportunity to talk about our commitment to security, the defense-in-depth strategy that we have taken, and how other aggregator developers might benefit from the work we have done.

Our commitment to security

To put it bluntly, we are keenly aware that IE is a target for security researchers and hackers. We know we cannot afford to be lax in how we approach security. It has therefore been our #1 guiding principle that we would aim for a secure experience first -- sacrificing functionality, if necessary, to achieve it.  

Long-time readers may remember this post from last November, in which we announced that we would only support well-formed XML in feeds -- the post was the direct result of a long internal discussion about ways to securely handle malicious feeds. Refusing to handle malformed XML eliminates a large class of potential attacks.

Walter posted last month on the details of how IE7 and the Windows RSS Platform protect users and developers from script in feeds. To summarize what he wrote, IE7 employs a (roughly) two-level defense-in-depth strategy:

  • Sanitization: First, the Windows RSS Platform uses several techniques to strip out script (and several other variations of malicious HTML) before storing the feed content.
  • Restricted Feed View: Second, just in case the first step misses something, IE's feed view uses a variation on the Restricted Zone to show a feed, meaning that no script in a feed will run, even if made it through the previous step.

Each of the two defense-in-depth steps described above require a significant amount of code and investment, but security has been always important enough to us that they where the first major pieces of development that we did when we began implementing the RSS features. In fact, these security features have been in place since the first public release of the IE7 RSS platform features last February.

To give you a sense of what is involved -- at one point in development, the sanitization code accounted for fully one-third of all the code in the RSS platform. The code takes lessons from similar libraries used for years to clean the billions of messages that Hotmail receives, and used for a number of releases in various parts of Office.  It includes a number of feed-specific additions (for example, if an element is supposed to only contain text, then we can remove all HTML, not just the script). We validate and sanitize every documented element in each format we support, as well as a set of common RSS extensions. This is all done before an item is ever stored on the system.

In IE itself, the "restricted feed view" was also a significant challenge because of the interactive nature of a feed view. We designed and developed a feed view that required no javascript for the various controls (subscribing, filtering, sorting, or searching) to work. In fact, the IE7 feed view implementation is effectively that described by Nick Bradbury in his recent post on feed security (using a script-less page, and manipulating the view from the hosting code).

The bottom line is that IE takes security very seriously. We have invested a great deal of time in hardening IE7 across the board, and nowhere more seriously than in our RSS features. It is an ongoing process, however, and we deeply appreciate the efforts of those in the community who have developed additional security tests and allowed us to use them.

Looking forward

We also look forward to continuing to work with the community to improve the security of all aggregators. To that end, we want to make a couple offers to developers of Windows aggregator developers: 

  • First, you should feel free to contact us if you have questions that come up while implementing a fully restricted feed view using the techniques that Nick talked about in his post. If there is enough demand, we may write a blog post on how the IE feed view is built, so people can learn from what we’ve done. 
  • Second, the Feeds API includes a utility function called Normalize(), which can be used to gain access to the platform's HTML sanitization code. Contact us if you'd like more information on how you could use this to supplement your own sanitization code. 
  • Finally, I’ll make the obvious point that the entire platform is available for your use, including not just the security features described here, but storage and a suite of bandwidth management features. I understand, of course, that for many existing aggregator developers, switching storage and download engines may be too significant a change in their applications, but I do want to encourage developers of new applications to consider it.

Thanks for reading,
Sean

PS. Of course, there will be some readers who see this post as a challenge and start looking for exploits in IE's RSS features. If you do find any, please let us know! :) We know that no security is perfect, and that it is an on-going process.