DOM based XSS... is it worth knowing about it?

Although DOM based cross-site scripting isn't something new, it is often confusing as of how it is a valid threat to web applications. After all, some may say that if all input goes through the web application before it's displayed on a page, then there is no way to differentiate DOM based XSS from Reflective or Persistent XSS. This assumption, however, is a bit misleading.

Let's take a look at some key points that make this kind of XSS differ from the others:

• Transformation of data. While most data validation occurs with respect to server-side usage of the data, more and more applications adopt a model where data from the server-side is transformed in the browser before it's finally displayed to the user. Take for instance URL encoding. If a server-side routine URL encodes a string and the client-side code call the JavaScript unescape() function, then the URL encoding routine becomes useless. This being said, it is important that server-side validation takes into account possible transformations that can be done through client-side code.


• Sources of input. With JavaScript having access to the document.location property, it is possible for JavaScript code to take it's input independently of the server-side code. In such scenarios, attackers are allowed to directly bypass the server-side validation routines of the application.


• Keeping web applications client-side. As web applications are moving more and more toward Web 2.0 technologies such as Google Gears, AJAX, and Silverlight, client-side code will be often used to improve applications' performance by reducing the number of HTTP requests to the server-side parts of those applications. Therefore, client-side code must be designed carefully to not allow user input to be treated as executable content within a page.

If still not convinced that DOM based XSS can be real, observe a demo version before and during a cross-site scripting attack.