W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2013

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

From: Brad Hill <hillbrad@gmail.com>
Date: Wed, 3 Jul 2013 11:57:21 -0700
Message-ID: <CAEeYn8gn6FaKJOa1Tp5TJZ0+kx0KERFS=6hHxcbhPOGm30o3JQ@mail.gmail.com>
To: Ian Melven <imelven@mozilla.com>
Cc: WebAppSec WG <public-webappsec@w3.org>, dev-security@lists.mozilla.org, Sid Stamm <sid@mozilla.com>, "L. David Baron" <dbaron@mozilla.com>, Jonas Sicking <sicking@mozilla.com>
Ian, I think this sounds sensible.  (and bumping this back into the list's
consciousness - I too would like to see more comment)


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
Received on Wednesday, 3 July 2013 18:57:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:34 UTC