Every week or so I get the same question about XSS. What’s the worst thing cross site scripting can do? We’ve tackled the question from a somewhat crippled perspective, which is that we can attack the site you are on, or we can attack your intranet, or we can make you attack someone else on our behalf, etc… That might not sound crippled but it is. It’s dealing with XSS as if it were only one bug in one place, when reality the way the web is built, XSS is practically everywhere. It’s far more prevalent and easy to find than any other vulnerability.
On the boards yesterday, Maluc had a really brilliant thought. It’s not that you can XSS just one domain on which you find the vulnerability. But once you have control over the user’s browser through one XSS hole you can exploit others on other domains. This can lead to a massive cascading effect where you can have one XSS exploit that uses XSS in hundreds or even thousands of other domains to steal all the credentials and identity information that it can. As we’ve found nearly 1000 unique XSSs in huge companies, there is no doubt way way more that we haven’t touched. The only thing slowing this down is detecting which ones to try.
Not knowing which XSS to go for too can be mitigated using Jeremiah’s CSS hack. If the user has been to abcbank.com chances are they’ve logged in there, and chances are you’ll have a more successful time attempting to steal their credentials through a website they’ve been on. The CSS hack only takes a second or less to iterate through a thousand links, so this would take very little time in the user’s perception. In this way you can exponentially increase the information theft through a single web-page the user visits.
Taking this one step beyond Maluc’s original idea, let’s say you find a link from the website you’re on to another website that you have found a XSS hole in. Instead of loosing control over their browser once they move from one domain to another, why not change the link (to the homepage of xzysite.com) to another link on xyzsite.com that has an XSS exploit in it and then use XMLHTTPRequest with an XSS proxy to continue your attack.
If the user is currently using Internet Explorer, you can even try to re-write anything that goes to another domain into Flash using the Expect header or maybe use the mhtml vulnerability to get some cross domain leakage or to find other sites that may not be obvious to attack (the URL may not be right in the latter example but really, who watches the URL bar on every request?). Now you’ve got a potentially interactive XSS shell that follows a user across domains. It doesn’t matter if it’s not persistent, it moves with the browser on each request, or mimics what the browser should see by using XMLHTTPRequest and re-writing the page. Beautiful.
So… what’s the worst thing you can do with XSS? Steal every piece of sensitive information you’ve ever inputted or will ever input on any website you’re authenticated to. Yes, it’s potentially that bad.