Re: CSP and inline styles

On Tue, Oct 23, 2012 at 6:26 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/23/12 1:40 AM, Adam Barth wrote:
>> On Mon, Oct 22, 2012 at 7:31 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>> We should just block all inline
>>> style and be done with it, instead of worrying exactly how it was set.
>>
>>
>> That's another place to draw the line.  Do you have spec text you'd
>> like to propose for doing that?  It's easier for me to think about
>> these sorts of changes with concrete text.
>
> Sure.  How about:
>
>   Declarations that come from style attributes, in the sense of CSS 2.1
>   section 6.4.3 first bullet point, are not applied.

Interesting.  I didn't think to look at the selector specificity rules
for a definition of inline style, but I think that should work.

>>> I still have to see a clear definition of the inline style behavior in
>>> this
>>> spec.  Everything I have seen so far has basically required
>>> reverse-engineering UAs to understand what the spec is trying to say.
>>
>> Can you explain what is unclear about the text that is currently in
>> the spec?  I'm happy to improve the clarity of the requirements, but
>> I'm not sure we agree about what behavior we're trying to specify.
>
> OK.  For purposes of the following examples, assume that "doc" is a document
> with a CSP that has "style-src unsafe-inline" and that the scripts are
> running in the context of a different document which has no CSP applied.
> It's not clear to me, from the spec's current language whether the styles
> are applied in these examples, because it's not clear to me what it really
> means by "from a style attribute" in terms of actual processing model.
>
> So examples:
>
>   // Example 1
>   var el = document.createElement("span");
>   el.setAttribute("style", "color: red;");
>   doc.body.appendChild(el);
>
>   // Example 2
>   var el = document.createElement("span");
>   el.style.color = "red";
>   // Note that now both the CSSOM and the DOM of "el"
>   // are the same as in example 1
>   doc.body.appendChild(el);
>
>   // Example 3
>   var el = document.createElement("span");
>   el.setAttribute("style", "background: purple;");
>   el.style.color = "red";
>   doc.body.appendChild(el);
>   // Is the color applied?  Is the background?
>
> Basically, the problem with the current spec language is that if the intent
> is that example 1 be blocked but examples 2 is not blocked then either you
> have to keep track of the provenance of each declaration (not acceptable to
> me) or the blocking happens at a particular point in time and is not a
> state.  But the spec does not clearly define what that point in time is,
> unfortunately.  Is it at the moment the setAttribute call happens (so that
> the styles in example 1 above would not be blocked), or something else?

Thanks for explaining this issue.  I didn't not understand that from
your previous messages.

> If it's something else, then what exactly is supposed to happen in example
> 3?
>
> Basically, what I want from the spec is to either define the blocking as a
> state function, so that it's possible to determine by examining the state of
> an element (its DOM, CSSOM, and any internal flags this specification
> defines) to determine whether style is applied, or to define an actual
> processing model if the behavior is order-of-operations dependent.
>
> Does that make sense?

Yes.

The underlying issue appears to be that we have different processing
models in our heads for how the style attribute and the CSSOM produce
style information for elements.  From reading the above, it appears
that your model is that the CSSOM is just a fancy way of generating a
string that gets stored in the style attribute.  That's why you view
Example 3 as difficult to interpret.

It's clear from <http://html.spec.whatwg.org/#the-style-attribute>
that mutating the CSSStyleDeclaration causes the style attribute's
value to change, but it's not clear whether the computed style for the
element flows directly from the CSSStyleDeclaration or via the style
attribute.  In your understanding, it's the latter whereas my view is
the former.

style attribute -> CSSStyleDeclaration -> CSS engine
style attribute -> CSSStyleDeclaration -> style attribute -> CSS engine

In any case, hooking into the processing model at CSS 2.1 section
6.4.3 does seem like a cleaner approach.  I'm happy to make that
change.

Adam

Received on Tuesday, 23 October 2012 15:37:13 UTC