- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Wed, 9 Dec 2009 12:09:03 -0500
- To: sird@rckc.at
- Cc: public-web-security@w3.org
On Wed, Dec 9, 2009 at 4:45 AM, Eduardo Vela <sirdarckcat@gmail.com> wrote: > We presented on Microsoft Bluehat this ppt (CSS The Sexy Assassin): > http://tinyurl.com/cssattacks The attacks seem to fall into four basic categories: 1) Obfuscation techniques. These are only an issue if sites aren't sure to handle escapes correctly. I'm sure some don't, but those sites are probably full of XSS already for the same reason. :) There's not much to do on a spec level if server-side sanitization doesn't handle basic parsing right. 2) Clickjacking. Extensively discussed already, I think. I haven't followed the discussion much, but my impression is that the only good solution anyone's thought of is prohibiting framing (e.g., via X-Frame-Options). 3) Attribute sniffing using CSS3 selectors. Was discussed here. This seems to only result in an exploit if your injected CSS is already capable of stealing IP addresses of a site's visitors, so it doesn't seem to be a huge increase in attack surface. 4) :visited exploits. Extensively discussed already for what, a decade now? It's basically impossible to prevent a JS-based attack unless you carefully whitelist allowed CSS property values for :visited rules -- JS could inevitably detect changes in things like font-size just from their effect on layout. A CSS-only attack should be preventable if browsers just fetched resources unconditionally when they were in a :visited rule, rather than on demand (right?); but that's not much use, since almost everyone has JS enabled. The conclusion I've seen is that it's just not worth the effort to try preventing this.
Received on Wednesday, 9 December 2009 17:09:31 UTC