Stealing Data with CSS: Attack and Defense(mike-gualtieri.com)

Stealing Data with CSS: Attack and Defense

https://www.mike-gualtieri.com/posts/stealing-data-with-css-attack-and-defense

12 comments

Buge8 anni fa

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

zawerf8 anni fa

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

anglebracket8 anni fa

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

gruez8 anni fa

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.

cdumler8 anni fa

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.

deathanatos8 anni fa

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

anglebracket8 anni fa

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.

auditrrre8 anni fa

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.

limeblack8 anni fa

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

matbilodeau8 anni fa

Well thanks for the info and the protection plugin :)

[deleted]8 anni fa

telechair8 anni fa

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/