873302 - [CSP] implement unsafe-eval for style-src per CSP 1.1. spec

Status: NEW

(Core :: DOM: Security, enhancement, P3)

Description

[Sid Stamm [:geekboy or :sstamm]]

We may want CSP inline style blocking to also block calls to CSSOM setters (much like eval in scripts).

In bug 763879, dbaron wrote:

My preference (though sicking and bsmith have slight disagreement) for what needs to be blocked when unsafe-eval is not present is all CSSOM setters other that:
 * direct property setters
 * direct selectorText setters or similar (keyText)
 * direct media query setters
which basically means blocking:
 * all .cssText setters
 * anything that allows inserting a complete rule (my biggest compat worry here is keyframe and @keyframes rules)

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Stamm [:geekboy or :sstamm] from comment #0)
> We may want CSP inline style blocking to also block calls to CSSOM setters
> (much like eval in scripts).

Not "inline style" (unsafe-inline) but unsafe-eval. The proposal is to have style-src: unsafe-evel control (certain parts of) use of the CSSOM in the same way that script-src: unsafe-eval controls eval() and friends. The idea is that parts of the CSS OM that modify the object model are acting like an interpreter of CSS in an analogous way to the way eval() and friends interpret Javascript.

The basis of dbaron's thinking and sicking's thinking is that there are some parts of CSS that are always "safe" so that, even if those elements are attacker controled, nothing bad can happen. According to this line of thinking, for example, there is little or no harm in accidentally letting an attacker control the value used to set the background-image property, for example.

The basis of *my* thinking is that I am skeptical that we can say that any and all CSS values that we've implemented are safe; even if we could somehow demonstrate that what we've implemented so far is safe, it seems incredibly unlikely that future additions to CSS will have the same safety properties. Consequently, my suggestion is to treat the entire CSS OM as unsafe insofar as setting properties and/or calling methods that modify the CSS OM are concerned. But, any read-only properties of the CSS OM would be unaffected. 

element(selector)/-moz-element(selector) is an example of a CSS value that I think is already questionable as far as safety is concerned. Would allowing an attacker to choose a background property of element(selector) allow data exfiltration and/or spoofing and/or phishing attacks? I haven't convinced myself either way yet. Given -moz-element(), I also wouldn't be surprised to see future extensions to CSS such as attribute-value(selector) or element-text(selector) which would clearly facilitate exfiltration attacks if used as an attacker-controlled value to set even seemingly-benign properties like height/width. 

I also question whether developers can accurately learn and retain the classification that dbaron outlined in comment 0 in their heads. Since use of the CSS OM in scripts is an extremely common use case, we need to make sure that we specify this in a way that is easy for developers to understand and use.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Brian Smith (:bsmith) from comment #1)
> The basis of dbaron's thinking and sicking's thinking is that there are some
> parts of CSS that are always "safe" so that, even if those elements are
> attacker controled, nothing bad can happen. According to this line of
> thinking, for example, there is little or no harm in accidentally letting an
> attacker control the value used to set the background-image property, for
> example.

I don't think anyone is saying that "nothing bad can happen". Just that "it's so unlikely enough that something bad will happen that we don't need a way to turn it off".

This is equivalent to how we have no feature in CSP for turning off "[foo]" accessors in JS, even though they permit a page to do:

window[a][b][c](d, e, f);

which is a very dangerous expression.

> The basis of *my* thinking is that I am skeptical that we can say that any
> and all CSS values that we've implemented are safe; even if we could somehow
> demonstrate that what we've implemented so far is safe, it seems incredibly
> unlikely that future additions to CSS will have the same safety properties.
> Consequently, my suggestion is to treat the entire CSS OM as unsafe insofar
> as setting properties and/or calling methods that modify the CSS OM are
> concerned. But, any read-only properties of the CSS OM would be unaffected. 

We've made similar judgement calls in the past. I.e. we have chosen to treat SVG images like other images, even though it's entirely possible that SVG images will grow features that make them substantially different from other image formats. In fact, SVG already have a very different feature set, some of which we disable in SVG images, some of which we don't.

CSS is similarly being designed with the security model of the web in mind. If CSS grows radically new features like expression() I think it's safe to say that either

* It will be designed such that it doesn't radically change the security model of CSS. For example see calc().

or

* We will know about it early enough that we can define how these new features interact with CSP. I.e. we can say that if CSP is used these features are disabled by default unless enabled through additional "unsafe-*" tokens for style-src.

Most likely both of these things will be true.

> element(selector)/-moz-element(selector) is an example of a CSS value that I
> think is already questionable as far as safety is concerned. Would allowing
> an attacker to choose a background property of element(selector) allow data
> exfiltration and/or spoofing and/or phishing attacks? I haven't convinced
> myself either way yet. Given -moz-element(), I also wouldn't be surprised to
> see future extensions to CSS such as attribute-value(selector) or
> element-text(selector) which would clearly facilitate exfiltration attacks
> if used as an attacker-controlled value to set even seemingly-benign
> properties like height/width. 

Another point here is that this is unrelated to CSSOM and its capabilities. If element(selector) is dangerous and meaninfully different from the rest of CSS, should we really enable it if a page simply uses style-src?