W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

Re: Risks from CSS injection

From: David Lindsay <thornmaker@gmail.com>
Date: Tue, 8 Dec 2009 15:12:12 -0500
Message-ID: <2e7df85e0912081212t166fe5f0me519fdf5f388bf59@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: gaz Heyes <gazheyes@gmail.com>, Adam Barth <w3c@adambarth.com>, Daniel Glazman <daniel@glazman.org>, Thomas Roessler <tlr@w3.org>, public-web-security@w3.org
On Tue, Dec 8, 2009 at 13:54, Maciej Stachowiak <mjs@apple.com> wrote:

> A) Sites that voluntarily include untrusted CSS (such as user-provided)
> without filtering being exposed to data theft risk.
> B) Sites that have inadvertent CSS injection risk (but without the
> possibility of script injection) being exposed to data theft risk.
> C) Both.

Both are interesting scenarios that an attacker can theoretically abuse.

Not explicitly mentioned, but also of interest are CSS attacks that
can be performed only in CSS and not in JavaScript.  In such cases, it
doesn't matter whether or not JavaScript is enabled.  For example, the
privacy issues surrounding :visited selectors falls into this

> One thing to keep in mind is that including untrusted CSS is already
> extremely risky. If the attacker can inject CSS (whether willingly or not)
> he or she can do the following:
> 1) Arbitrarily move around elements on the page.
> 2) Make any element invisible.
> 3) Replace the visible contents of elements with chosen images or text.
> 4) Overlay one element invisibly on top of another.
> Using these, you can make the "Delete Account" button look like a "Mail me a
> Free Pony" button. This isn't even counting features like -moz-binding or
> CSS expressions.

Yes, restyling the page is also interesting for phishing and
clickjacking (or UI redressing).  However, the ability to do so
doesn't obviate the utility (for an attacker) of the other attacks
being discussed.

> Thus, any site doing voluntary injection of CSS must do whitelisting to be
> safe. Any site with inadvertent CSS injection holes is already at great
> risk.

Agreed.  However the ability to mitigate some of these attacks through
whitelisting doesn't mean we shouldn't explore eliminating some of
these attack vectors in the first place.

Sites that have inadvertent injections will most likely be vulnerable
to JavaScript injection which is allows a lot of more direct and well
understood attacks.  Again, that doesn't mean we shouldn't explore
what other attacks are possible with CSS and see if they can be
mitigated or eliminated via small design changes to the standards.

Received on Wednesday, 9 December 2009 09:26:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:23 UTC