Mitigation, get your site added to the HSTS Preload list.<p>Most of the advanced webappsec security features leak information. CSP, HPKP, HSTS, etc, which was all 100% known.<p>This talk is excellent because it puts together the attacks into real PoCs, real attacks, and great information on how it all works. These attacks in the talk are quality too, instead of being 'mostly' theoretical.<p>This wasn't really documented all in one place, or as high quality in the past. Way to go @bcrypt. High quality work.
Probably a good idea to edit the title to indicate that this is an example attack site as well, not my favorite thing in general to land on without warning.<p>No js seems to mean no worries though.
The site attacks seems to fail in Tor Browser. It returns a list of sites that have nothing to do with my browser history.
Probably because Tor Browser reduces the time precision.[1]<p>It seems like it would be nice to require some sort of user privilege escalation like accessing location, or webcam to access high precision timing. This would close off a huge class of time related side channels.<p>[1]<a href="https://trac.torproject.org/projects/tor/ticket/1517" rel="nofollow">https://trac.torproject.org/projects/tor/ticket/1517</a>
I hit the page from Chrome 45.0.2454.101 and it literally did not get a single site that I regularly visit. It did make a hit on Reddit, I guess, but I have only visited the site two or three times, and you could probably say that about 2/3 of the population.
The root problem seems to be that the web security model is broken because you can get onload AND onerror callbacks from img coming from 3rd party sources regardless of CORS.<p>You are not allowed to read the content of those resources for security reasons, and the fact that you can detect whether they have been loaded seems just as broken (although obviously this usually only has privacy impact, while reading the contents easily allows impersonating the user or stealing secrets).<p>This attack abuses this by using HTTP URLs and causing HTTPS to trigger onerror by using a content security policy that disallow HTTPS, which allows to measure timing of the HTTP->HTTPS redirection, which is instantaneous if the site had already been visited due to HSTS caching.<p>So I think two changes are needed:<p>1. The browser should never fire onerror on non-CORS-allowed 3rd party resources, but instead fire onload even if an error happens<p>2. The onload event should ideally be triggered 1 second after the resource has been seen regardless of whether it has been loaded or not. If that breaks too many websites, the timing granularity should be rounded to the greatest period possible.<p>There is also the problem of lots websites having CORS policies that allow * , so should probably also fix browsers to not allow sites to have CORS * policies, at least for this purpose.<p>Alternatively, it might be possible to load those resources normally, but effectively consider them to be a "3rd party origin from 1st party origin" that is different from "3rd party origin" and from other 1st party origins for all caching purposes.<p>However, this seems risky because if the 3rd party site manages to somehow fingerprint the user (e.g. because the IP address is whitelisted) then that information is potentially leaked to the 1st party site. For example, it would be possible to detect whether your IP is whitelisted by a domain that otherwise returns errors to everyone.
Having disabled NoScript, Privacy Badger, HTTPS Everywhere, and AdBlock Pro, it can tell I've been to npmjs.com. I'm not immediately worried.<p>Maybe too obvious to point out, but as far as I can tell, it looks for entries in the browser cache, rather than looking at the history per-se. If you have the browser cache empty when you close the browser (gotta watch those evercookies!), that's also not an issue.
This approach is rather interesting.
But I'm wondering whether a similar attack could be made by placing links on a web page and using the CSS :visited selector to change the style of visited web pages. Couldn't you then check which links have that formatting and which don't via JS?
I think many popular sites will be a false positive because some browsers ship with a list of HSTS domains.. visiting them in HTTP first wouldn't happen. <a href="https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json" rel="nofollow">https://code.google.com/p/chromium/codesearch#chromium/src/n...</a>
Strange. I disabled "scripts from 3rd party sites" and "frames from 3rd party sites" by default in ublock origin and this site successfully loads 329 external JS ressources from other sites (none are manually enabled). Does anyone have the same problem? Is this a bug of ublock origin or expected behaviour?
A slide discussing HSTS+CSP attack (this one) and also HPKP attack: <a href="https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf" rel="nofollow">https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf</a>
The core issue is the same that leads to cross domain search timing attacks [1] (which can be prevented with CSRF tokens)<p>With timing HTTP->HTTPS redirections maybe the issue is not that the response can be timed but that HTTP exists in the first place? There are other similar timing attacks that can easily be used to identify if a user is logged in to a specific website [2].<p>[1] <a href="https://news.ycombinator.com/item?id=10211306" rel="nofollow">https://news.ycombinator.com/item?id=10211306</a>
[2] <a href="http://crypto.stanford.edu/~dabo/papers/webtiming.pdf" rel="nofollow">http://crypto.stanford.edu/~dabo/papers/webtiming.pdf</a>
Hm, tried this on my Android phone first and it didn't seem accurate - might have found 1 or 2 sites I actually visited, a few I wasn't sure of, and would randomly change between reloads. Seems to work much better on desktop Chrome (win 7). Wonder why there's a discrepancy.
I'm using Chrome 46.0.2490.80 without HTTPS Everywhere and it couldn't find any site I visited (tells me I visited none). I tried to visit a few and restart the test, it didn't found anything either<p>Edit : retried in Firefox 41.0.2, it's giving accurate results
Thankfully, this particular attack does not work with a running µmatrix. I do see a bunch of image requests to all these domains, but it shows that I haven't visited any (except for the ones that are blocked completely by hosts files, amusingly enough).
I was skeptical at first, then I visited some of the sites it said I had not visited. A second round caught them, eep! A little machine learning could probably make this much more accurate, the PoC is clear.
Are timing attacks over the internet affected by buffer bloat?<p>Not a single positive even though I have visited a number of the sites on the list. There's even tabs open for Reddit right now.
this worked on an older version of chrome for me, but not the recent ones -- the sites listed were incorrect.<p>additionally, some alternative browsers based on chromium also gave inaccurate results when used on ipad and android.<p>this is strictly based on my exp w/ my own machines. im a security researcher so maybe my machines exhibit more unconventional settings / environments that are atypical of the avg user.<p>will try again later on a different machine. this is interesting stuff,good work.
A different version of this would of been to mess around with the :visited css selector since it's assuming a list of domains that you probably visit
Luckily I have taken out entire classes of attacks against the browser (this one included) using simple, baseline configs that harden the browser. I am unsure how many people take these measures and I don't know the stats for how many people are hardening their browser in some way, but I suspect large swathes of web users are at risk here.<p>Since this is Hackernews, my efforts to educate the masses on weaponized browser attacks like this would be futile, and I am sure many have configured their browser in some rudimentary way to merry away the assholes.<p>There is a certain sigh of relief and 'ha catch me if you can' that coats me when I see PoCs like this rendered obsolete and inert.