3 ms·

I don't think this can really be blamed on CSS. I mean, yes, a new CSS feature allowed a timing attack that could extract information, but these kinds of issues

by lambda 8y ago

I don't think this can really be blamed on CSS. I mean, yes, a new CSS feature allowed a timing attack that could extract information, but these kinds of issues keep on coming up time and time again, meaning that it's not this particular CSS feature that should be blamed. The issue is the ability to interact in any way with cross site resources which contain any kind of potentially sensitive information. This leads to things like clickjacking attacks, CSRF, information leaks like this, and so on. The things that could be done to fix it: 1. Don't allow any kind of cross-site embedding (yeah, this isn't going to happen) 2. Treat any kind of cross-site embedding like private browsing mode; don't ever send any credentials along with it 3. Don't allow the embedding site to interact in any way with embedded content. Treat it like an entirely separate, opaque layer above everything else, not subject to layering anything over it Of course, I don't think any of these are actually going to happen, because they'd break too much. But otherwise, it's going to be a game of whack-a-mole with information leaks, new kinds of clickjacking and CSRF, and so on.

blattimwind 8y ago
> 3. Don't allow the embedding site to interact in any way with embedded content. Treat it like an entirely separate, opaque layer above everything else, not subject to layering anything over it I'm actually surprised to hear that this is not the fix here. Instead, they optimized the rendering code, which might not preclude more sophisticated attacks on that side channel.
- anglebracket 8y ago
  That's similar to what Kaminsky proposed with Iron Frame[0], but obviously it'd have to be opt-in. Applying Iron Frame-like rendering to all iframes would break a lot of content. [0]: https://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/ https://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickj...
- mattnewton 8y ago
  As noted elsewhere, this would cause sites with models or menus to appear broken, when the menus or models are stuck behind the iframe. Yes I know, don’t make sited with iframes and litghtboxes or whatever then, but people do, and the option they chose won’t break those people.
the8472 8y ago
You can get 2. more or less in firefox with privacy.firstparty.isolate = true or various container extensions Or one could write an extension that sets sandbox attributes on iframes. I'm not sure if one exists yet.

by lambda 8y ago

blattimwind 8y ago

> 3. Don't allow the embedding site to interact in any way with embedded content. Treat it like an entirely separate, opaque layer above everything else, not subject to layering anything over it I'm actually surprised to hear that this is not the fix here. Instead, they optimized the rendering code, which might not preclude more sophisticated attacks on that side channel.

anglebracket 8y ago
That's similar to what Kaminsky proposed with Iron Frame[0], but obviously it'd have to be opt-in. Applying Iron Frame-like rendering to all iframes would break a lot of content. [0]: https://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/ https://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickj...
mattnewton 8y ago
As noted elsewhere, this would cause sites with models or menus to appear broken, when the menus or models are stuck behind the iframe. Yes I know, don’t make sited with iframes and litghtboxes or whatever then, but people do, and the option they chose won’t break those people.

the8472 8y ago

You can get 2. more or less in firefox with privacy.firstparty.isolate = true or various container extensions Or one could write an extension that sets sandbox attributes on iframes. I'm not sure if one exists yet.