Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Can't this be done with Javascript?

I welcome opportunities to avoid javascript in my sites, even if it's more work for me. It makes life easy for visitors who prefer to disable javascript, thereby avoiding many of the exploits, trackers, etc. that plague the web today.

By the same token, I appreciate sites that do not require javascript.



Is there a future where CSS’ expanding surface area leads to exploits and tracking? For instance, some time ago I saw an article about how font face rules can be used to fingerprint users


Yes and yes. You’ve already pointed out fingerprinting, but there are other attacks that can be done.

See:

- CSS keylogger, 2018: https://github.com/maxchehab/CSS-Keylogging

- OWASP cites CSS injection as a mechanism for XSS and data exfiltration: https://owasp.org/www-project-web-security-testing-guide/sta...

Luckily we haven’t seen new classes of attacks here, but being concerned about attack surface of any browser technology is valid and reasonable.


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...


Honest question. Is really "animations" a thing related with styling?

IMHO, I see all those bells & whistles more related to scripting than to styling. I'd prefer to be able to navigate with Javascript disabled and not having to suffer some superfluous animations, but maintain the styles.


At least in terms of animations being superfluous, there's an accessibility setting to reduce animations that at least built in browser CSS animations can reliably respect, whereas with hand-coded Javascript animations, you're relying on each individual author to write code to respect that setting.


I hope someone chimes in to correct me if this is wrong, but AFAIK CSS animations are not automatically disabled by toggling such a setting.

Original idea puts it under the authors control to add @prefers-reduced-motion media queries.

Might be that some browsers do this anyway, otherwise it would be easy with a user script or user style sheet.

This article argues for the spirit of the spec:

https://css-tricks.com/nuking-motion-with-prefers-reduced-mo...

> “animation isn’t unnecessary.”

It has a point, intrusive animation's main bastions are not CSS-based anyway.

For example, there seems to be a continuous (JS- and HTML-based) cat-and-mouse game that makes me require an ad blocker to disable autoplay videos on news sites, regardless of browser preferences.

This part is like the DNT header all over again, incentives don't align.

And the lesson should be that CSS is the most benign battle site for this issue, because it is customizable and not yet locked down behind anti-debugging and obfuscation techniques.




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

Search: