XSS track got ninja stealth skills thanks to HTML5

XSS-Track, a point of concept project on how to track users through XSS vulnerability today got even better: now it can change URL in browser address bar as you navigate through the site, making it even more transparent for the victim.

It is possible thanks to a HTML5 feature - window.history.pushState(). It was created for AJAX websites so that they could easily change window location bar and manipulate history. Read more about the it on WHATWG site.

It's a great and convenient feature for developers - for example, AJAX apps can now easily support back & forward buttons without resorting to URI fragment identifier (#) hacks. But it can also be used for malicious purposes. Basically, in HTML5 you can no longer trust the location bar. For security reasons, specs say you can only change a path (i.e. not hostname, port etc.) and of course it is subject to same-origin restrictions but that is enough for XSS-Track. So now we have these convenient functions in XSS-track source code:

var getPath = function(url) {
  return url.match(/(\/.*)/)[1];
};

var changeAddressBar = function(url) {
  try {
    // html5 goodness - should work in Safari, Chrome, FF 4
    window.history.pushState({}, "", getPath(url));
  } catch(e) {}
};

and navigating a link within vulnerable domain will update the address bar path accordingly, making XSS-track practically invisible (unless you click an external link).

Disclaimer:
window.history.pushState() works in Chrome 5, Safari 5 and Firefox 4 and more browsers will come in future. When it's not available, XSS-Track will just leave the URL of a vulnerable page, so we're forward compatible. Try and hack the demo site to see the effects in one of those browsers to see it in action. HTML5 FTW!

XSS-Track: How to quietly track a whole website through single XSS

XSS is #1 threat in web application security. We all know it's pretty common, from time to time we encounter a website where a single input field is vulnerable. Happily we send out alert(document.cookie) only to find out that session cookie is httpOnly (it's a good sign!). On the other side we know that XSS gives us, white hats, an almost unlimited potential on how to alter the vulnerable page. We can:

• deface it,
• steal user's form values
• redirect to form a phishing attack
• look at cookies
• try to send malware through a drive-by download attack
• and many more...

However, what to do if we found a vulnerability on one page, and all the interesting things are on the other page on the same domain? Say, the vulnerability is on http://vulnerable.example.com/search and we'd really like to steal user's credentials from http://vulnerable.example.com/login-form? Of course, with JS it's possible, but usually it's a difficult manual process to construct such payload. Today I'll present a way that makes it dead easy to:

• track user's actions on a vulnerable website (clicks, form submits),
• track outside links,
• monitor pages content and report any interesting HTML elements (e.g. the secret credentials)

All of this is possible with a single injected script - think XSS-injected Google Analytics! With just one XSS vulnerability on any page an attacker gets information about all browsing actions of unsuspecting user. Demo inside!