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!

BBCode won't protect you from XSS

Cross site scripting (XSS or HTML injection) is a vulnerability class that allows an attacker to enter malicious HTML code into your document. Usually that's a Javascript code for e.g. stealing the cookies or self spreading worm used for social networking sites. All the big sites (Facebook, Twitter, Myspace, Wikipedia to name the few) have had an XSS hole in the past. What that can teach us is that XSS protection is usually done wrong. Developers invent yet-another-perfect XSS filters, WAFs update their signatures, even the browsers feature XSS protection nowadays. And still, most of them fail.

One of the wrong ways to protect from XSS is to use BBCode. Today I encountered yet another blog post (update: post deleted by author, see comment #1) claiming that author used a BBCode implementation so that "The code is encoded and perfectly safe and resilient to possible XSS attacks". I just just had to put that to a test. Read on to find out how "perfect" was the code and what is wrong with using BBCode for XSS protection.