Paid Advertising
web application security lab

CSS History Stealing Acts As Cookie

Matan, Jeremiah and I have been chatting a bit lately around the CSS history stealing hack that Jeremiah came up with and presented at his Blackhat talk a few weeks ago. One of the ideas Matan came up with I think is worth posting, because it really does show a rather interesting application for CSS history stealing that I hadn’t thought about before.

In its simplest form, once a user visits a certain web page an attacker could choose a random unique id for the user and then force him to visit a URL (through a hidden iframe) containing that unique ID. Then on a subsequent visit the attacker can make the user iterate through all the unique ids that it ever generated and see if the user visited any of them. If he did, then the attacker can know the user has already been to his site. Furthermore, the URL with the unique id can point to a script that stores and retrieves the data the attacker would like to save for the user.
Of course, in the real world this wouldn’t work well because as the number of visitors increases, so do the number of URLs a user would have to iterate through. When it comes to thousands or millions of users this could take quite a while. To solve this, an attacker can use a hierarchy of folders (or most likely virtual folders that don’t even exist). So let’s say you have a special folder /spy/ on the web server. This folder contains numbered subfolders 0-9. Each of these folders would contain 0-9 more subfolders. The nesting of the folders could be around 10 folders deep which means the site can hold 10^10 unique ids. Then the attacker can generate a random path for the user and force him to visit each of the folders in the path (so the final path would look like /spy/3/6/8/1/7/2/3/4/8/9). In this example it would take 10 URL accesses to reach the end of the path. So once a user enters the site again he would have to iterate through a maximum of 10 * 10 links in a worst case scenario. Of course, security-wise for the attacking site this is bad as random users would be able to impersonate other random users and mangle their stored data. But this can be overcome by generating valid paths using an algorithm only the website knows and most complete paths will lead to a dead end.
Do you think this could work?

Yes, yes, it very easily could. This is actually an interesting way to get around some of the issues really large sites have with companies like AOL that have massive super proxies with upwards of 30k people behind a single IP address. You can “cookie” them in this way with a relatively small footprint compared to an actual cookie (which is often killed anyway by security products or turned off entirely by paranoid/malicious users) and upon a user repeat visit you can detect them once again. It’ll be interesting to see how this attack evolves over time, as I am sure there are dozens of other interesting ways to use these attacks. Special thanks to Matan!

4 Responses to “CSS History Stealing Acts As Cookie”

  1. Martin J. Says:

    Two related links from academia:

    Cache Cookies for Browser Authentication - - a paper that describes a similar technique, in this case used for authentication (feels like a bad idea to me)

    Protecting Browser State from Web Privacy Attacks - - A project at stanford, that applies the same-origin policy to the browser history to counter CSS based cache sniffing. They have developed PoC Firefox to demostrate their concepts.

  2. Dave Says:

    How long is the browser history normally stored?
    I see, in Firefox the standard value is 9 days, which ist not really a long time.
    All the “internet privacy” tools delete the browser history anyway, so you probably won’t get the “paranoid” users.

  3. RSnake Says:

    Martin J, those are interesting, I’ll have to look into those a bit more.

    Dave, paranoid no? But it’s an interesting application for what is essentially only a cross domain leakage tool.

    I store my history for oh… the length of a session. But I would hardly qualify anyone who reads this blog as the kind of person who would be at risk for these types of issues anyway, for a myriad of reasons.

  4. » History Stealing Script Says:

    […] Eine weitere, nicht so unethische, Möglichkeit dieses Script zu nutzen findet man bei ha.ckers. Dort ist “Matan” auf die Idee gekommen den Code als Cookie zu verwenden. So lässt sich mit einigem Aufwand ein Besucher trotz extremen Sicherheitsvorrichtungen noch identifizieren. […]