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

CSP and inline styles

From: Ian Melven <imelven@mozilla.com>
Date: Fri, 8 Feb 2013 13:11:39 -0800 (PST)
To: public-webappsec <public-webappsec@w3.org>
Message-ID: <280116179.1652528.1360357899943.JavaMail.root@mozilla.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 8 February 2013 21:12:07 GMT