Hacker News new | past | comments | ask | show | jobs | submit login

https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and...

They try to sandbox it.

There are more clever ways now. Like... everything you interact with is a binary search into a projection of your (2^n-interaction) "guess"-ed/history.

If you interact with it, then it is assumed that you can see it.

Even detecting if the room is generally lit or not via the Ambient Light API can be paired with bright and dark elements to ping flashes off your face, in a dark room, to read whether or not elements were of that certain color.

But lets scrap :Visited and use arcane browser implementations and user behaviors; even something as innocuous as zooming slightly in or out is a session-persistent signal. The browsers explicit and even _inferred_ zoom level can be leveraged. A few irrational numbers and difference in spec implementations and your zoom level on Compromised_Site_A can identify you exactly from Compromised_Site_B even without Javascript.

But let's reset zoom between domains. Easy? sure.

But something still has to get painted to the page, like images, that could be cached....depending on how long they have been visited, and from what domain, and from what order. And the timing between all those are almost certainly unique to few, and sensitive to all.

If you load a thumbnail from Bad_site_a within 100ms in a country that blocked the original resource....thats a paddlin.

Those are just the first few, I could go on.




More than half of the examples you listed only partially use CSS as part of the exploit chain and could be done without CSS at all. For instance, you can certainly flash the screen but CSS is never going to be able to, on its own, read and exfiltrate the data necessary. You're relying on things like access logs at that point.


  CSS is never going to be able to, on its own, read and exfiltrate the data necessary.
CSS knows a lot, and it can send it back via image requests, triggered in states through animations, 'lazier'-loading, unqie font-choosing, etc.

https://blog.sheddow.xyz/css-timing-attack/

  You're relying on things like access logs at that point.
Well, yes. The timing and unique request path make identifying possible. And CSS can be dropped in context by other users, crafted to refer to a different domain, so CSS worms can definitely ex-filtrate data without the webmaster being evil.


uBlock, I exfiltrate: exploiting ad blockers with CSS

https://portswigger.net/research/ublock-i-exfiltrate-exploit...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: