Hacker News Reader

Comment by gruez | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com