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?
Timing attack against HSTS to sniff browser history in Chrome and Firefox
71–80 of 99 posts
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#72The 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…
You still can insert external image into a page and poll its size either directly or detect it via layout changes.
Maybe the root problem lies in HSTS and browsers using HTTP by default (because that is why we need HSTS)?
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#73Strange. 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?
It loads images, not JS, if I understand correctly.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#74Wow. Our corporate proxy isn't going to like that many requests that quickly from one box. I wonder if they can add a landing page.
Any picture/script heavy main page (news etc) probably produces the same number of requests
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#75Hm, 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.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#76Hm, 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.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#77The 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…
You still can insert external image into a page and poll its size either directly or detect it via layout changes. Maybe the root problem lies in HSTS and browsers using HTTP by default (because that is why we need HSTS)?
Indeed, should disallow that as well, e.g. give such external images and videos an intrinsic size of 1/3 the browser window size regardless of their actual size.
And disallow (non-CORS-allowed) cross-domain JavaScript and CSS.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#78Earlier quoted context omitted.
You still can insert external image into a page and poll its size either directly or detect it via layout changes. Maybe the root problem lies in HSTS and browsers using HTTP by default (because that is why we need HSTS)?
Indeed, should disallow that as well, e.g. give such external images and videos an intrinsic size of 1/3 the browser window size regardless of their actual size. And disallow (non-CORS-allowed) cross-domain JavaScript and CSS.
It would be easier to disallow http-only CSP though.
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#79Strange. 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?
It loads images, not JS, if I understand correctly.
Ah, thanks! That why these external ressources are shown but not blocked. Interesting attack vector!
Re: Timing attack against HSTS to sniff browser history in Chrome and Firefox
#80The 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…
firing onload instead of onerror for a cors failure seems heavy-handed - the ajax spec says cors failure should be treated as network failure, and while that can cause headaches it seems even worse to say something loaded when it in fact didn't. I don't really see a sane behavioral choice here. TBH I'm unsure there's a sane recommendation to make here that will solve the privacy leak problem without causing significant pain for the internet - knowing when something loaded or failed can be extremely useful. And besides, if you block onload / onerror handlers, you can possibly just change the POC to use CSP error reporting, and try to timing attack that instead.