Re: CSP and inline styles

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?

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

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.

Simply relying on default-src doesn't seem great. Maybe treating those
as style-src would reduce the attack surface here.

>> 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?

>> * doc.body.style.background = "...";
>> * bgcolor attributes appearing in the markup
>> * <font> elements appearing in the markup
>> * doc.body.appendChild(doc.createElement("font"));
>> * doc.body.bgcolor = "...";
>
> These are not blocked.

I'd rather determine the criteria to use rather than declaring in/out
for these just yet.

>> However, in https://bugzilla.mozilla.org/show_bug.cgi?id=763879#c33 Jonas points out:
>>
>> "The data-stealing attack described in the article below could be done using just element.style.background = ...;
>
> That's correct, but we need to stop somewhere.  An attacker who can
> inject markup into a document cannot add code that assign arbitrary
> values to element.style.background.  The page needs to do something
> more to be vulnerable.
>
> It's not entirely obvious to me where to draw the line as to what to
> block.  The spec draws it in an easy-to-define place that also
> mitigates the largest risks.  We could mitigate progressively obscure
> risks by blocking more things, and we could potentially block less
> things without getting into too much security trouble.

I agree that we need to draw a line and that it's non-obvious where to
draw that line. Looking at it from the point of view of specific
attacks seems like a good idea to me.

I would say being worried about defacement attacks by using
positioning/colors/borders/etc is not something we should worry about
since the cost is too high and the risk relatively low. However
network requests is something that I would worry about.

>> So while it might "feel" safer, it's arguably not.
>>
>> http://scarybeastsecurity.blogspot.com.es/2009/12/generic-cross-browser-cross-domain.html "
>
> It doesn't have anything to do with "feeling" safer.  It has to do
> with being beyond the capabilities of the attacker we're trying to
> stop.
>
>> There is more discussion in bug 763879 about what mechanisms in the above list are equivalent and what
>> the important distinction when evaluating these mechanisms is, and if basing it around if the
>> mechanism is equivalent to inserting a <style> node goes far enough - my personal opinion agrees with a
>> statement from Jonas : "The critical distinction isn't whether you have to call a JS function in
>> order to launch the attack. The distinction is whether that function parses strings into harmful content."
>
> I disagree with Jonas.  An attacker who can inject markup cannot call
> JavaScript functions (at least when CSP stops such an attacker from
> injecting script).  Therefore, attack vectors that require calling
> JavaScript functions are beyond the attacker's capabilities and
> therefore less worrisome.

Yet you are saying that setAttribute("style", ...) and
createElement("style")... should be blocked. And I assume that we all
agree that eval() should be blocked when inline script is blocked.
Even though all of these require calling javascript functions.

The concern here isn't that the attacker injects a JS function call.
The concern here is a page doing something like:

x = getData3rdPartyData();
y = getUserPrivateData();
body.style.background = x + y;

Code like this would allow a 3rd party to ship user data home. It
relies on function calls, yet doesn't require the third party to
inject any function calls into the page.

/ Jonas

Received on Monday, 22 October 2012 23:51:31 UTC