Security features (like any software features in general) are additional vulnerability vectors prone to implementation flaws.
Timing attack against HSTS to sniff browser history in Chrome and Firefox
91–99 of 99 posts
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#92Mitigation, get your site added to the HSTS Preload list. Most of the advanced webappsec security features leak information. CSP, HPKP, HSTS, etc, which was all 100% known. 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. This wasn't really documented al…
> Mitigation, get your site added to the HSTS Preload list. If that could scale, we wouldn't need DNS? Come to think of it, as ip addresses aren't distributed, why not have HSTS be a flag in DNS, rather than a header? (Yeah, I know, because DNS isn't secure - but that's the real problem, right there...).
Or, if the site you're visiting is DNSSEC enabled, you could just look for a TLSA record. If the TLSA record is present, don't allow unencrypted connectivity.
That's probably how you could replace HSTS with DNS.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#93The 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. 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 cont…
> 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.
That would be horrible. Just to take my own site as an example, I embed thumbnails that expand to the full image when clicked upon. The image is first loaded through javascript, and my code waits for onload, so that my code knows the expected dimensions, then the image in the DOM gets the new URL and transitioned to the new size. Adding a delay here would make everything much slower and less pleasant to use.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#94I 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.
interesting, are you using any browser addons? please file a bug at https://github.com/diracdeltas/sniffly , thanks
In Chrome I am running ABP, which can't be very uncommon, Evernote web clipper, rest console, xpath helper, and a bunch of Google's own shims. I will file a bug later today if I can repro the results.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#95I 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. https://code.google.com/p/chromium/codesearch#chromium/src/n...
Preloaded HSTS entries are filtered out https://github.com/diracdeltas/sniffly/blob/c645af76cb53a21a...
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#96Does not seem to work without Javascript enabled.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#97Probably 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. No js seems to mean no worries though.
Honest question: what is your concern?
Any link you click could possibly contain a hidden attack, perhaps a malicious one.
If this link had been labeled differently, would you not have clicked?
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#98Earlier quoted context omitted.
> Mitigation, get your site added to the HSTS Preload list. If that could scale, we wouldn't need DNS? Come to think of it, as ip addresses aren't distributed, why not have HSTS be a flag in DNS, rather than a header? (Yeah, I know, because DNS isn't secure - but that's the real problem, right there...).
Or, if the site you're visiting is DNSSEC enabled, you could just look for a TLSA record. If the TLSA record is present, don't allow unencrypted connectivity. That's probably how you could replace HSTS with DNS.
Even without DNSsec, HSTS could pretty much work as advertised.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#99this worked on an older version of chrome for me, but not the recent ones -- the sites listed were incorrect.
additionally, some alternative browsers based on chromium also gave inaccurate results when used on ipad and android.
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.
will try again later on a different machine. this is interesting stuff,good work.