- From: Ian Melven <imelven@mozilla.com>
- Date: Fri, 8 Feb 2013 13:11:39 -0800 (PST)
- To: public-webappsec <public-webappsec@w3.org>
Hi, i've brought up the inline style section of the CSP 1.0 spec [1] on the mailing list before and also discussed it in person with a few working group members as well as inside Mozilla. While implementing inline style blocking in Gecko, one subject that has come up repeatedly is that of which threats from inline styles we are attempting to address. The threats that have been brought up so far that I'm aware of are : * using selectors to steal passwords * exfiltrating data via setting properties that cause a request to be made to a remote server (subject to eg. img-src and other CSP directives) * altering the appearance of the page in some way aka defacement Currently, selectors can only be used in linked style sheets and <style> elements. There have been concerns raised that selectors may be allowed in other pieces of CSS, including attributes, in the future. The spec says : ----- "If 'unsafe-inline' is not in allowed style sources: Whenever the user agent would apply style from a style element, instead the user agent must ignore the style. Whenever the user agent would apply style from a style attribute, instead the user agent must ignore the style. Note: These restrictions on inline do not prevent the user agent from applying style from an external stylesheet (e.g., found via <link rel="stylesheet">). The user agent is also not prevented from applying style from Cascading Style Sheets Object Model (CSSOM). [CSSOM] ------ There has been some debate about the usefulness of blocking modification of style attributes while allowing style modification via CSSOM. For example, allowing modification via CSSOM means loaded style sheets (allowed by any style-src/default-src restrictions), can be modified by script. The cssText attribute allows arbitrary CSS properties to be set, as does setProperty(). What about SVG elements ? These can also modify many arbitrary styles, as can SMIL animations. We have also seen some anecdotal reports (supported by our own experience with FirefoxOS) that style-src: unsafe-inline is considered essentially required for a CSP, which has made a few of us wonder about its value in its current form. Brian Smith has suggested that perhaps we could make the inline style blocking in CSP more granular, breaking it down into something like unsafe-inline-element and unsafe-inline-attribute, for the purpose of making it more feasible for policy authors to address the most serious threat that has been discussed. This is easily backwards compatible: unsafe-inline == unsafe-inline-element and unsafe-inline-attribute. Additionally, script injections should hopefully be blocked via the script restricting portions of CSP, which is a further mitigation against malicious modification of style attributes, ie. unsafe-inline-attribute would be more a defense in depth, while restricting script doesn't help in the case of an element injection. Thoughts/feedback very welcome ! thanks, ian [1] http://www.w3.org/TR/CSP/#style-src
Received on Friday, 8 February 2013 21:12:07 UTC