W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2012

CSP and inline styles

From: Ian Melven <imelven@mozilla.com>
Date: Mon, 22 Oct 2012 15:02:30 -0700 (PDT)
To: public-webappsec@w3.org
Cc: Jonas Sicking <jonas@sicking.cc>
Message-ID: <1505013075.3415444.1350943350889.JavaMail.root@mozilla.com>

Hello,

As part of our work to implement the CSP 1.0 spec in Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=663566),
we have been looking at what we need to do to block inline styles (https://bugzilla.mozilla.org/show_bug.cgi?id=763879)

The reason for this post is that we need more discussion among the WG (and possible clearer guidance in the spec) as to what
threats blocking styles is intended to address and what threats are considered out of scope for this
restriction (eg if it's intended to stop data exfiltration).

Additionally, we could really use clarification in the spec as to what methods of applying CSS should be blocked in a CSP 1.0 compliant UA
(and this would hopefully lead to more consistency across implementations).

Previously on this mailing list, we discussed blocking mechanisms that apply CSS that
are equivalent to inserting and parsing a <style> node in the DOM. 

Specifically, we considered the following list of ways to apply CSS: 
(from https://bugzilla.mozilla.org/show_bug.cgi?id=763879#c26) 

* doc.body.appendChild(doc.createElement("style"));
* doc.body.setAttribute("style", "...");
* doc.body.style.background = "...";
* bgcolor attributes appearing in the markup
* <font> elements appearing in the markup
* doc.body.appendChild(doc.createElement("font"));
* doc.body.bgcolor = "...";
* doc.body.innerHTML = "<style>...</style>";

However, in https://bugzilla.mozilla.org/show_bug.cgi?id=763879#c33 Jonas points out: 

"The data-stealing attack described in the article below could be done using just element.style.background = ...;

So while it might "feel" safer, it's arguably not.

http://scarybeastsecurity.blogspot.com.es/2009/12/generic-cross-browser-cross-domain.html "

There is more discussion in bug 763879 about what mechanisms in the above list are equivalent and what
the important distinction when evaluating these mechanisms is, and if basing it around if the 
mechanism is equivalent to inserting a <style> node goes far enough - my personal opinion agrees with a
statement from Jonas : "The critical distinction isn't whether you have to call a JS function in 
order to launch the attack. The distinction is whether that function parses strings into harmful content."

Your thoughts are very welcome. 

thank you !
ian
Received on Monday, 22 October 2012 22:02:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 October 2012 22:02:59 GMT