On 10/22/12 6:28 PM, Adam Barth wrote:
>> * doc.body.setAttribute("style", "...");
>
> These are blocked.
>
>> * doc.body.style.background = "...";
>
> These are not blocked.
Once again, these are functionally equivalent given cssText. And it's
actually _more_ work, both in spec terms and in terms of implementation
(at least in Gecko) to block one but not the other. So I'm still not
sure why we're blocking one but not the other... We should just block
all inline style and be done with it, instead of worrying exactly how it
was set.
> That's correct, but we need to stop somewhere. An attacker who can
> inject markup into a document cannot add code that assign arbitrary
> values to element.style.background.
Nor can they call setAttribute, yes? So why are we blocking the
setAttribute version?
Or are we just trying to block parser-triggered attribute sets and it
happens to be hard to distinguish those from scripted attribute sets in
some implementations?
> It's not entirely obvious to me where to draw the line as to what to
> block. The spec draws it in an easy-to-define place
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.
Again, it would be easier to just spec that inline style is not applied,
period.
-Boris