information leak: check if user is redirected by arbitrary url

[martin....@gmail.com]

It's possible for a website a.org/ to check whether the user is redirected by b.org/path1 to b.org/path2. This often leaks private information if the redirect on b.org/ depends on the users state. For example, if the user is only redirected to b.org/path2 if he's logged in on b.org/, a.org/ can detect whether the user is logged in on b.org/ or not.

The basic idea and more ideas how to exploit this are described in this pdf: https://www.checkmarx.com/wp-content/uploads/2012/07/XSHM-Cross-site-history-manipulation.pdf (for a short explanation see "Login Detection Technique" on page 6).

I've implemented a proof of concept here: http://jsfiddle.net/wdp59rt5/
It checks whether the user is logged in on deviantart.com

I'd like to point out that this is not a timing attack, but it exploits the fact that, when loading a site in an iframe, the browser behaves differently based on whether the same site has been loaded before or not. A new entry in window.history is only created for the loaded site if the same site has not been loaded before.

Do you think it would be desireable to prevent non-timing-based redirect detection?

[Sid Stamm]

On 09/16/2014 04:58 AM, martin....@gmail.com wrote:
> It's possible for a website a.org/ to check whether the user is redirected by b.org/path1 to b.org/path2. This often leaks private information if the redirect on b.org/ depends on the users state. For example, if the user is only redirected to b.org/path2 if he's logged in on b.org/, a.org/ can detect whether the user is logged in on b.org/ or not.
>
> The basic idea and more ideas how to exploit this are described in this pdf: https://www.checkmarx.com/wp-content/uploads/2012/07/XSHM-Cross-site-history-manipulation.pdf (for a short explanation see "Login Detection Technique" on page 6).
>
> I've implemented a proof of concept here: http://jsfiddle.net/wdp59rt5/
> It checks whether the user is logged in on deviantart.com

This uses window.history.length to figure out if something has been
visited recently (by forcing another visit), right?

I'm curious: how is this affected if I have multiple tabs open? And how
quickly can you check a bunch of URLs? This seems very much like bug
147777.

-Sid

[martin....@gmail.com]

Am Mittwoch, 17. September 2014 22:28:16 UTC+2 schrieb Sid Stamm:
> This uses window.history.length to figure out if something has been
> visited recently (by forcing another visit), right?

Tecnically speaking, the script can't detect which websites the user visited, it only detects redirects (by figuring out which url is loaded in an iframe). But of course, if you appear to be logged in on e.g. deviantart, it's safe to assume that you have visited this site before.

Apart from that: Yes, the demo uses window.history.length and it forces another visit of the url it's interested in.

> I'm curious: how is this affected if I have multiple tabs open?

The script can only detect which website is displayed in the iframe (and which websites have been displayed earlier in the iframe). It's not possible to figure out which websites the user has visited outside of this iframe, e.g. in other tabs. So it doesn't matter if the user has multiple tabs open. But again, if the user appears to be logged in on e.g. deviantart (in the iframe), we can assume that he visited deviantart before. He could have done so in the iframe, but he could as well have done so in another tab.
But for websites that have no redirections which depend on the user state, the script cannot detect whether that website has been visited.

> And how quickly can you check a bunch of URLs?

The script could use many iframes in parallel and check one url per iframe. I don't think there's a limit of how many iframes the script could use, but the bottleneck in this case is the loading and rendering of the websites. In my tests, it takes about 25 seconds to load http://www.wikipedia.org in 100 iframes. You can test it yourself with this jsfiddle: http://jsfiddle.net/uennyjfe/1/
If it would be possible to prevent the rendering or even the loading of (some) resources in the iframes, the whole process could be sped up a lot.

The demo script needs two page loads in the iframe per redirect check. This can be reduced to one page load per redirect check (by appending an #anchor to the url for the second visit). So, the fastest solution I have found takes about 250 ms per url. Of course this depends on the users Firefox settings and computer performance. Also, there might be tricks to speed this up.

> This seems very much like bug 147777.

As explained above, the script doesn't check which websites have been visited, but where the user is redirected by a certain url. The result is in a large part the same as in bug 147777: we can find out what the user has been doing. For the difference between what we can do with the technique described here and bug 147777, let's look at an example:
We want to check whether the user has admin privileges on b.org/.
To do so, we check whether b.org/adminpanel redirects the user to b.org/insufficient_privileges. If not, the user has admin privileges.
Using :visited-Links, the detection of admin privileges would not work. If a user without admin privileges visited b.org/adminpanel and was redirected to b.org/insufficient_privileges, b.org/adminpanel would still count as visited. Also, a user with admin privileges would have to actually have visited b.org/adminpanel. And third, using :visited links to gain information about the user is quite hard since :visited links have been limited to having different colors.

On the other hand, :visited links can be used to detect which websites have been visted by the user without requring a redirect on the website that depends on the user state.