Cenzic 232 Patent
Paid Advertising
web application security lab

Why XSS is Here to Stay

On the drive to work today, I started wondering what it would take to stop cross site scripting. Not from a website perspective - because god knows that’s such a huge task it would take forever to accomplish. But rather, what would happen if all the browsers, on the same day at the same time decided to shut off remote script includes? That would be great from a web application security perspective, but what exactly would break if that happened? A lot is the short answer, but here are a few things that make Fortune 500 type companies rely on it:

Analytics Yup, you can thank the likes of Google, Omniture and Hitbox for making JavaScript counters that do more than count, but also gather statistics that are only availible in JavaScript space. If remote JavaScript was turned off the only alternative would be to include some local proxy, to call the local dynamic page and proxy that information back to the analytics programs. Even huge companies would rather use their data warehouse only for auditing or spider analytics (which fly under the radar of JavaScript reporting systems) and use these JavaScript includes as the primary source for information about their site.

Contextual Banner ads Here you can thank the banner companies (Google and Overture primarily) for increasing the placement of dynamic banner ads all over the web. In doing so they have made a huge dependence on remote JavaScript for revenue generation (this site is no different).

AJAX Information super-highway 2.0, here we come! Tons of applications are starting to request off host XML files to include in their website. It’s the new way to deliver content without refreshing the page. If we got rid of it, what would happen? Well, we’d probably go back to refreshing the web-page, or using some other cross domain software, like Flash. I doubt anyone is giving up on this one any time in the near future.

Akamai I love Akamai in concept. Caching is a huge part of performance on big website design. If you can throw your static content, like images and, oh, JavaScript on remote hosts that cache that content for you, you can dramatically decrease load time and processor power. It’s sexy, and it’s here to stay. Too bad it forces me to allow JavaScript from everywhere if I want to see “Hello, RSnake” on the top of the websites I visit.

Page load and SEO Going hand in hand with Akamai is that big companies don’t want to include all the JavaScript on their page because it dramatically slows down the time it takes to render the page. The reason is because it is not cacheable if it’s a dynamic page (which large companies typically have a lot of). Also, if you are very bandwidth conscious and you have a ton of cookies you don’t want their browser sending those cookies over and over again (typically upstream is always slower than downstream too), so you are better off keeping the JavaScript off host so cookies aren’t sent in transit on every request. Additionally, spiders discount JavaScript in terms of SEO (search engine optimization). So keeping JavaScript on the page reduces the relevance of the content on your page.

All of those things together (and probably a lot of other things I haven’t thought of as well) make it pretty clear that there’s no way big companies are going to lobby the browser companies to shut off remote script sources. They want them. It’s good for business. It’s terrible from a security perspective, but there you have it. There are mitigating factors, sure, but the concept isn’t going away. And speaking from experience, you can’t surf without JavaScript turned on all the time. Tons of websites force it (thanks, Adsense and Orkut!) forcing their users into a lower state of security, regardless of their intentions. So we continue to fight the issues on the server instead.

5 Responses to “Why XSS is Here to Stay”

  1. Dean Brettle Says:

    How about this proposal:

    Change browsers to maintain a whitelist of domains (or perhaps more generally URL patterns) that javascript is allowed to talk to. To avoid redirect attacks, the the final (after redirection) domain/pattern would be checked against the whitelist as well. Allow each users to add to their browsers’ whitelist, and most importantly, allow each page to add to the whitelist that is used for javascript on that page. There are at least 2 ways to do that last bit. One would be to use a special element in the head section of the page (where it is pretty hard to inject). The other would be to add AddToWhitelist() and CloseWhitelist() functions to javascript. Pages would have javascript in the head element to call those functions. Once CloseWhitelist() was called AddToWhitelist() would no longer work.

    Thoughts?

  2. Dean Brettle Says:

    BTW, something similar could be used to prevent CSRF. Links that don’t match the whitelist would be displayed differently to warn the user. Other uses of URLs that aren’t on the whitelist (e.g. images) would not be allowed.

    Of course, all of this would still allow same site script injection and request forgery.

  3. RSnake Says:

    Hahah, these threads are starting to converge… we are having a similar discussion here: http://ha.ckers.org/blog/20060830/defensive-xss-and-seo/

    This is very close to the initial discussion I was having around content-restrictions with Mozilla last year. It’s a good idea, in whatever incarnation it comes out in. It’s already been submitted to the WHATWG but thus far I don’t know that anyone has done much more than propose it.

  4. Dean Brettle Says:

    Thanks for the links. Great reading - very thought provoking.

    I think my proposal can be broken into two parts. The first is a very stripped down version of content restrictions. Specifically, it’s just the domain restriction perhaps generalized to an url pattern restriction. The second part is a default whitelist maintained by the browser. That default whitelist is critical because it is the difference between waiting for web page authors to secure their sites and allowing non-technical end users to take matters into their own hands.

    The key question is whether it is possible to construct a whitelist that would provide meaningful security without a lot of breakage. Here’s a strawman:

    In an attempt to handle most of the Akamai-style cases, the default whitelist for a page from www.example.com allows *.example.com. Basically, we ignore any leading “www” or “web” and whitelist hosts which match the remainder of the domain name. That might need some tweaking.

    I’m willing to let analytics and contextual banner ads run because the company on the whitelist is the company responsible for them. So we add the appropriate url patterns for Google and it’s competitors to the whitelist.

    Ditto for companies that provide popular XML web services.

    The browser would obviously need to be capable of automatically updating the default whitelist to handle the case where a whitelisted site is compromised.

    Companies that aren’t on the default whitelist would need to convince their clients to add an HTTP header whitelist that includes them.

  5. RSnake Says:

    I like where you’re going with this. To be the devil’s advocate:

    What would the HTTP header include? A link to an XML file that had these whitelists in them? What about exceptions (certain pages may have different needs)? Also, what if the attacker gets control of the header (response splitting or otherwise)?