81–90 of 99 posts
Edit : retried in Firefox 41.0.2, it's giving accurate results
Earlier 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.
Earlier quoted context omitted.
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.
But I don't think this solves the whole problem, as the time to "redirect + load https image" v. "HSTS redirect + load https image" is probably significant enough of a difference to timing attack. In which case you just need to time the onload of an image (or similar resource).
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].
[1] https://news.ycombinator.com/item?id=10211306 [2] http://crypto.stanford.edu/~dabo/papers/webtiming.pdf
Earlier quoted context omitted.
It would be easier to disallow http-only CSP though.
this sounds like a good idea. I do have to wonder if you use CSP & https for your own site (because what site deploys CSP without deploying https first?), what sort of http-only directives would even be legal (i.e could successfully load content) under mixed-content rules. But I don't think this solves the whole problem, as the time to "redirect + load https image" v. "HSTS redirect + load https image" is probably si…
Earlier quoted context omitted.
The JS code sent to kentonv's browser might be safe, but you can't really meaningfully comment on hobs' situation, since you don't have a copy of the JS code that was sent to hobs' browser.
Actually I can. The author of this code is a friend of mine who works with the EFF, and the idea that she's secretly sending malicious scripts to some people but not others from her MIT web hosting space under her own name is simply not plausible.
In all seriousness, I appreciate the added context your (particularly this last clarifying comment) add to the discussion.
Mitigation, 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…
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...).
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. No js seems to mean no worries though.
While I probably would have linked HN to the slides instead of the site, I do think calling it an attack site is paranoid and disingenuous.
Wasnt looking to castigate the author, just looking for a title with a warning.
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.
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.