Re: CSP 1.0: Lax and strict CSS parsing rules

On Fri, Mar 1, 2013 at 2:23 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Mar 1, 2013 at 10:15 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>>   <http://www.w3.org/TR/2012/CR-CSP-20121115/#security-considerations>:
>>
>>   The style-src directive restricts the locations from which the
>>   protected resource can load styles. However, if the user agent uses a
>>   lax CSS parsing algorithm, an attacker might be able to trick the user
>> agent into accepting malicious "style sheets" hosted by an otherwise
>>   trustworthy origin.
>>
>>   These attacks are similar to the CSS cross-origin data leakage attack
>>   described by Chris Evans in 2009. User agents should defend against
>>   both attacks using the same mechanism: stricter CSS parsing rules for
>>   style sheets with improper MIME types.
>>
>> I do not understand this text, starting with why user agents would load
>> non-text/css resources as style sheets into `style-src` restricted
>> documents. It does not say what web sites can do to proect against this
>> kind of attack, or how using "stricter parsing rules" is a defense for
>> the user agent. More importantly, I do not understand how to comply with
>> the "SHOULD" requirement here: what actually are these "stricter rules"?

I had a hand in the research mentioned, and I wrote a
general-audiences introduction to it here:
http://www.owlfolio.org/htmletc/css-data-theft/  This particular
attack was always a little confusing because it's "inside out" from
more common web exploits.  It is critical to understand these three
points:

1) The CSS parser is not "lax", but it has standardized, predictable
error recovery rules (this is intentional: it's the foundation of
CSS's forward compatibility mechanism).  These rules can be exploited
to extract information from a document which is not supposed to be
interpreted as CSS (e.g. an HTML document).

2) It is the ATTACKER who causes the user-agent to load a non-CSS
document as a style sheet.  That document comes from the TARGETED
website.  (This is the part that's "inside out" from more typical XSS
exploits.)

3) The defense Chris Evans proposed in 2009 came in two forms,
"strict" and "lenient".  The "lenient" defense is now obsolete; all
browsers -- including fully patched up IE6! -- now implement the
"strict" defense.  (The document you quote seems to be confused on
this point.)  The "strict" defense does not involve changing how the
CSS parser behaves; it only involves changing *whether or not the UA
will feed a resource to the CSS parser*.

> Summary is that in order to be loaded, a stylesheet must either have
> a Content-Type of text/css, have no Content-Type at all, or be both
> same-origin and in quirks mode.

This is correct.  But, to reiterate, this is the condition for whether
the stylesheet is *loaded at all*.  If this condition is not met, the
CSS parser never sees the resource.

(It's on my "eventually" TODO list to figure out whether the modern
web still needs the "no Content-Type at all" or "same-origin and in
quirks mode" clauses of that condition.)

> (I guess technically this only
> applies to imported style sheets, not ones linked in via other
> document languages.  I think that's the technically correct choice.)

The loading condition above MUST be applied regardless of how the UA
came to load the resource.  Otherwise, the defense is ineffective.
(It's true that CSS specifications don't get to say how HTML's <link
rel="stylesheet"> works, but we mustn't let that stop us from giving
clear guidance to implementors.)

Furthermore, what matters is whether the resource being loaded is
same-origin with the *non-CSS document* at the root of an @import
chain.  Otherwise, again, the defense is ineffective.

And in the context of CSP, style-src MUST NOT override the above
loading condition: in other words, an UA MUST NOT load a cross-origin
document whose Content-Type is something other than text/css *even if*
style-src says it's okay.  Remember point 2: the attacker causes the
load.  Therefore, the attacker controls the CSP directives for the
document that triggered the load.

zw

Received on Friday, 1 March 2013 20:17:40 UTC