Solving the XSS Problem?

I want to start this out by saying I’m not a security expert. Which, in some ways, is a good thing. I’ve never once heard anything from a security expert that would even remotely work to fix the XSS problem we have in web development. A friend showed me a link today to some slides from an “expert” who claimed that not only is XSS the fault of JavaScript, but that the only way to fix it is to “kill” JavaScript.  Not only is this a completely incorrect evaluation of the problem, but even if it were the fault of JavaScript, replacing it would not be an acceptable solution.

The Problem

If you’re not familiar with XSS, or cross-site scripting, attacks, it has to do with outside parties getting their code on your site. When a malicious script gets on your site (generally through cross-domain scripts, although sometimes it even happens locally within a single site) it can do anything you, the developer, can: it can bring in new scripts, give and get information from any server in the world, potentially interact with your database, track user actions, etc. I don’t believe I need to go into detail in how many security issues this poses, it’s the web equivalent of a hacker getting complete control over your computer.

The Cause

In a large way, the overall cause of this vulnerability is the convoluted, over-complicated web platform, as a whole. JavaScript and CSS can both be external, and inline in HTML. They can have different encodings, and can be mixed and matched into each other in complicated and confusing ways. And what’s worse, the way JavaScript is integrated into a HTML document is atrocious; all scripts on the page share the same global namespace, and all scripts have complete access to everything in the document. Now, this is fine when you’re writing all your own code, there’s plenty of very good best practices out there that make this a non-issue. However, when external code, especially code linked from an external source, is involved you get what we have now: an unsettling uncertainty that all the code on your site is serving the interest that you think it is.

This is all very much an issue of the current web standards, particularly relating to HTML and browser security. The same-origin policy obviously is proven to be ineffective, and the standards require this poor model. And to make matters worse, they completely ignored this with HTML 5. Cross-side scripting attacks have been around since 1995, and since then no real work has been made to remedy the issue. In the HTML 5 specs, rather than focusing on this long ignored issue, they decided to add on to the web platform; add new elements, new features, and different functionality. This not only does not do anything to fix XSS, but in fact makes it worse. The more features we add the higher the potential for new techniques and methods for attackers, and the less we’re able to understand the web stack in enough detail to evaluate these issues.

The Cure

There’s no one fix, but the fantastic thing is that there are a lot of very good, and fairly simple ideas out there to fix this issue. First of all is the means of integrating scripts within an HTML document. The idea that all scripts should share the same global namespace is terrible. Ideally, there should only be one initial script that is introduced to the entire HTML document, maybe in a way similar to this:

And then additional scripts can be introduced through a dependency management system. Something similar to the API in Node.js would be the most logical:

var jQuery = require('js/libs/jquery-1.4.4.min.js');

Features and parts of the document could then only be accessed by external libraries through introduction; for instance, in a library you trust like jQuery you could pass the root DOM node to it for it to keep a reference of so that you can use it for DOM traversal and manipulation.

This would not only be a more secure model, but enforces very good program design. This model would suggest a modular design, very much like my JavaScript Architecture example I proposed in an earlier post, but this time in a far stricter way: all modules would quite literally only have access to their respective elements, and modules that are not related to a part of the document would have no possible way to mess with the page.

The same goes for integrating CSS. There already exists the functionality for including additional stylesheets into another one, so what’s the necessity for multiple link tags? I think the more sane approach would be virtually identical to what I proposed for specifying the document JavaScript:

This doesn’t necessarily effect XSS attacks, but it’s a nice design pattern and for once provides uniformity to the web platform.

I firmly believe that this approach, or one like it (I don’t claim to be a genius coming up with the end-all be-all solution) would not only solve XSS, but provide a programming model that could make front end development an order of magnitude better, and result in some really great code written and awesome web applications (and less crappy, unmaintainable code!). Will anything like this ever be done? Who knows, I hope, but we all know that changing something once it’s already been added to the web platform is not exactly trivial and rarely happens. But, we can all, as a development community, work towards this goal, and hope for the best.