Re: Content Security Policy: inline style blocking, CSSOM and unsafe-eval

Ian, I think this sounds sensible.  (and bumping this back into the list's
consciousness - I too would like to see more comment)

-Brad


On Mon, Jun 24, 2013 at 1:06 PM, Ian Melven <imelven@mozilla.com> wrote:

>
> Hi,
>
> Mozilla has recently enabled CSP 1.0 support in desktop Firefox, starting
> with Firefox 23.
>
> the blog post at
> https://blog.mozilla.org/security/2013/06/11/content-security-policy-1-0-lands-in-firefox/
> contains details of the implementation, including how it differs from the
> previous Firefox implementation
> using the X-Content-Security-Policy header and the places where the
> implementation does not conform with the current CSP 1.0 spec.
>
> one question that came up during implementation of the inline style
> blocking part of the CSP 1.0 spec (as discussed
> within the WebAppSec WG and on its public mailing list) was whether to
> block CSSOM access via script, inline or not, when inline styles are
> blocked.
>
> My opinion :
>
> CSSOM access from scripts which the CSP allows to run (either via an
> appropriate script-src source or script-src: unsafe-inline being present)
> should not require style-src: unsafe-inline to be specified.
>
> Ideally, a CSP will not specify script-src: unsafe-inline, since doing so
> negates a lot of CSP's benefit, so script injections that would
> try to do evil things via the CSSOM will be blocked already.
>
> A benefit of not requiring style-src: unsafe-inline for CSSOM access is
> that a page author doesn't need to opt into
> style-src: unsafe-inline if their page requires some kind of dynamic
> styling, which can be done via a script whitelisted
> via script-src (note that this case doesn't require script-src:
> unsafe-inline).
>
> However, I share the concern raised by others that the CSSOM can do
> dangerous things and user (attacker) supplied input can find its
> way into strings passed to CSSOM modifying functions.
>
> Brian Smith summarized a proposal for blocking CSSOM access based on the
> presence (or not) of style-src: unsafe-eval :
>
> "The proposal is to have style-src: unsafe-eval 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." [0]
>
> There is further discussion of this proposal in
> https://bugzilla.mozilla.org/show_bug.cgi?id=873302
>
> The proposal makes sense to me - much like script-src: unsafe-eval
> requires script to already be running (ie allowed by CSP somewhere), the
> threat
> is taking strings, possibly composed of user/attacker supplied input, and
> passing them to functions that evaluate them. I think it's valid
> to compare CSSOM functions to eval().
>
> Requiring unsafe-eval for CSSOM access is also similar to Jonas Sicking's
> idea which I raised earlier on the WebAppSec WG public list [1] :
> to have a CSP directive to restrict use of .innerHtml.
>
> That idea is also aimed at restricting use of APIs that can lead (have
> led) to security vulnerabilities via user/attack supplied input. There
> seems to be at least some amount of support for this idea.
>
> In fact, I suggest that it's possible to paraphrased and extend Brian's
> quote above as :
>
> "The idea is that parts of the CSS OM can modify the object model via
> string input are acting
> like an interpreter of CSS in an analogous way to the way eval() and
> friends can modify the object model via
> interpreting string input as Javascript and to the way .innerHTML can
> modify the object model via interpreting
> string input as HTML".
>
> which seems at least consistent, although the threat model for each case
> is not identical.
>
> what do others think of this proposal ?
>
> thank you for reading and considering,
> ian
>
> [0] https://bugzilla.mozilla.org/show_bug.cgi?id=873302#c1
> [1] http://lists.w3.org/Archives/Public/public-webappsec/2013Apr/0112.html
>
>
>