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 _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
