Wednesday, October 11, 2006

Predictions of DOM-Based XSS

More than 10 years ago the industry became aware of smashing-the-stack buffer overflows. Many exploits later, these issues became harder to come by in popular software. The industry then moved onto heap overflows in pursuit of greener pastures. Once the grass was eaten up, the next evolutionary step occurred, integer overflows came to be identified more often. My prediction for the next 3-5 years is DOM-Based Cross-Site Scripting (XSS), credited to Amit Klein, vulnerabilities will follow a similar path.

Today the vast majority of XSS vulnerabilities fall into the persistent (HTML Injection) or non-persistent (link click) variety. I expect most of these issues to be cleaned up on major websites. If fact I see this trend already as people become aware of the dangers. From there it’s reasonable to assume DOM-based XSS will grow in interest, where currently it lays in wait. For how long is the question.

DOM-based XSS has the spooky trait that the script injection does not traverse over the network. Meaning, web applications and web application firewalls are unable to filter or to block the attack. The vulnerability is actually burried inside the JavaScript code. We'll soon have to deeply educate ourselves on how best to spot these issues both by hand and through automated means. At the moment we have to sift through seas of JavaScript code, ugh.

As far as the next type of XSS, its has yet to be identified. ;)

5 comments:

Anonymous said...

Could you provide an example of DOM Based XSS ?

Andrew van der Stock said...

DOM based XSS:

User enters a value, such as username into a field. Say this function exists:

function validate()
{
var username;

try {

username = document.getElementByID("username");

// munge username somehow

}
catch ()
{
var errorMsg;
errorMsg = document.getElementByID("errorMsg");
errorMsg.innerHTML = "Username " + username + "invalid";
}
}

Then if you can insert arbitrary text into username, you can take over the DOM and play with it, starting with the script src tag and moving on from there.

Amit's paper has some concrete examples. I've got a demo which takes over the page and defaces it with the l33t 0wned kitten.

Andrew

Martin said...

Andrew's example seems not dangerous, because it needs users interaction (fill in something to username input box).

I have real-world story. One time I tested self-service terminals for unspecified bank, the access for web browser was limited only for bank's domain. There was apply form with very similar DOM based XSS vulnerability as in Andrew's example.

The terminal was Windows NT machine. So I typed on self-service terminal's keyboard the HTML, executed Outlook, from there I was able to execute anything and take full control of that machine:)

David Kierznowski said...

Jeremiah, your comment regarding DOM manipulation not traversing the firewall is by know means new but certainly a valid point. I think RSnake's Firefox plugin detection demonstrates this nicely.

Anonymous said...

You can execute JS in the context of the currently running page/domain by simply entering a javascript: URL in the location bar while the page is being displayed.

try it:
javascript:alert(document.cookie); foo

(the "foo" is important)