Stealing Data with CSS: Attack and Defense | Hacker News Reader

Stealing Data with CSS: Attack and Defense

mike-gualtieri.com

55 pointsbpierre11 comments

These only allow attacks where the desired data exists in the html of the page that the browser downloads (or can be forced there). You can also do font-based attacks that will steal data that is entered dynamically.

http://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode...

Do these work on reddit where you can have user submitted CSS stylesheets for your subreddits?

They shouldn't. These examples all rely on being able to cause an image load on a host the attacker controls if the CSS rule is applied. reddit blocks stylesheets that reference off-site resources. See https://github.com/reddit-archive/reddit/blob/master/r2/r2/l...

what's the threat model here? if the site owner is malicious, then sure, they can exfiltrate form contents while you have scripts disabled, but i'm not sure how you'd enter your SSN into a malicious site to begin with.

if it's via xss, i'm not sure what the advantage of this is compared to a javascript payload, other than you being able to get those tinfoil hat folks running noscript.

I think the take away is not that there is an attack vector. If the source is tainted then bad things happen. I think this is interesting in that it's _not_ source code but a CSS vector. If you're doing a security audit, sanitizing code is not enough. This attack vector uses side-effects of CSS to in-effect create obfuscated code.

Say the site has an XSS vector, but the site owner has taken the reasonable precaution of putting in a Content-Security-Policy that would disallow XSS from injecting <script> tags; this would seem to poke a hole in that protection. (Unless, perhaps, similar protections where applied to CSS, but I don't think most people expect CSS to do this; the attack outline in the article was novel (and clever) to me.)

Generally if you have a CSP without `unsafe-inline` you'd have have a policy that would restrict all subresources (`default-src 'none'`,) then punch holes in the policy by resource type (`img-src`, `script-src`, etc.)

For ex. if you have a proper CSP with `default-src 'none'` you should be fine so long as you didn't allow `*` or `unsafe-inline` in any of the other `<X>-src` directives.

This is useful if you have a reflective XSS that is getting blocked by xss auditor (like in chrome, safari) or a csp policy limiting script-src.

Yeah. If you want truly bad CSS injection go back to the IE6 days and Microsoft's expression() value.

Well thanks for the info and the protection plugin :)

It's odd the author thinks they're introducing the world to some new class of vulnerability. There's been a least a few presentations about it as far back as 2009, and is generally a known thing in web security.

[1]. G. Heyes, D. Lindsay, and E.V. Nava, “The Sexy Assassin: Tactical Exploitation Using CSS” (2009), http://slideplayer.com/slide/3493669/

[2] [CSSconf.eu 2013] Mike West - XSS. (No, the _other_ "S"), https://youtu.be/eb3suf4REyI?t=582

[3] https://twitter.com/blubbfiction/status/657632031845826560

[4] Demo PoC http://eaea.sirdarckcat.net/cssar/v2/

Reply on news.ycombinator.com