Paid Advertising
web application security lab

Exponential XSS Attacks

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 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 to another link on 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.

9 Responses to “Exponential XSS Attacks”

  1. zeno Says:

    Mind posting a sample snippet of code for this?

    - zeno

  2. RSnake Says:

    It would involve something like this:

    But tied in across domains with something like the Expect vuln (go here in Internet Explorer):

    Or if there is no obvious vuln you can still use the mhtml hack in IE to read the text across domains:

    I haven’t written a PoC, but you can see all of the puzzle pieces are there.

  3. Jungsonn Says:

    Nice indeed, it must be the tip of the friggin’ XSS iceberg that is out there, waiting for people to find and explore the potentials of it. It’s very exciting to see all these newly found ideas, Food for thought.

  4. pdp Says:

    Nice thought! However, the only problem is that you cannot exploit “hundreds or even thousands of other domains”. The browser allows you to make only two request at time. This is rather slow. However, I believe that with the raise of RIA this will change.

    Stealing the current user credentials and private information is great, however keep in mind that you cannot perform targeted attacks unless you use some kind of social engineering/phishing approach. This means that you can get some random users but not the one that you are really interested in. This is different compared to BF attacks so it will take some time for the audience to grasp.

    IMHO, the future is the social networks. Why? Well, they allow user content. This means that the chances for finding persistent XSS are quite high. Obviously, everybody is kind of part of one or another social community. For example or XSS hackers are in sla.ckers. This kind of attack can affect hundreds or even thousands of other users among whom you can find the ones you are really interested in.


  5. RSnake Says:

    That’s a good point. 2 requests at a time does slow you down a bit, but that’s probably not that big a deal if you’ve completely taken over their browsing experience through the mhtml issue. So you can just keep requesting until the user closes down their browser or surfs away from the shell. I bet you could get hundreds in a few minutes (assuming they aren’t bound by bandwidth issues). With the expect issue that shouldn’t be an issue because it only downloads what you tell it to. That combined with the browser history could dramatically speed up what you need to test for.

    But yes, you’re right, social networking is a huge issue.

  6. Mephisto Says:

    I would think that by using Jeremiah’s CSS hack you can target users who have been to certain websites. So in this respect you aren’t targeting a specific user, but a site that users may have been to, be authenticated against and still have a persistent cookie. With this then you could (theoretically) start sending out XmlHttpRequest’s to each site in the user’s history and possibly hijack their pre-authenticated session.

  7. RSnake Says:

    That’s what I was thinking too, yes. Any way to reduce the overhead of the sheer number of requests you would have to send out. Like most worms they are generally targeted, and in this case it would be targeted too. You probably don’t need to know their credentials for but you definitely would for and so on.

  8. maluc Says:

    Ah, i hadn’t thought of using mhtml as the cross-domain equivalent to .. you’ll be missing everything before the first double line return though, which you’ll probably need to retrieve with an external server somewhere.

    Another thing you could do, is if you control their browser at, and they click a link to - browse through the list of XSS attacks for and send them there instead. Then use XHR to pull the page the link was supposed to go to .. the domain will now match.

    And correct me if i’m wrong, but the two requests at a time are only for the same so if you’re trying to steal cookies for 800 unique domains that’s not really a factor. And i totally agree that the history hack should be done first to determine which sites to attack. i didn’t say so for brevity (my posts tend to be too long ^^). I think the two hardest parts to code will be to not bog down the browser so bad they close it, and sending all the information with a minimum number of external server connections.. it’s hard enough handling 1 connection for each of those 1million people.

    I’d recommend limiting it to 2-5 packets. The first packet for the most important sites/info .. and the rest divided among the remaining packets.

  9. RSnake Says:

    Somehow a few posts got deleted this morning:


    wow maluc gr8 idea, hell .. =)

    I cant wait to get my box running to have a closer look on this topic, sounds very interesting, there is much potential in XSS which came on the surface the past year