Re: In-browser sanitization vs. a “Safe Node” in the DOM

On Fri, Jan 22, 2016 at 1:53 PM, David Ross <drx@google.com> wrote:

> How, exactly, can we compute whether a given string is an anti-CSRF
> > defense token, and how, exactly, can we compute if CSS just leaked
> > it to the attacker? I don't immediately see how that security guarantee
> > is computable.
> We should probably talk about a specific version of the attack to make
> sure we're on the same page.  (Maybe this one:
> http://html5sec.org/webkit/test)
>

"""My suggestion for a fix would be: simply make sure that scrollbars and
their numerous components and states cannot request external resources once
they appear/change state -- but fetch their stuff onload so we can avoid
attacks like these. The only think making this attack work is the fact that
some parts of the scrollbar loads data from an external machine on
visibility/appearance -- and not on declaration in the style-sheet."""

So you propose to adopt that behavior for CSS applied to children of the
Safe Node?


> I think that if you're only detecting what you're describing above,
> it's too late.  My expectation is that CSS defined within the Safe
> Node would have no affect on the DOM outside of the Safe Node.  Is
> there some reason why this is not possible to implement or that it
> would be ineffective at addressing the issue?
>

I don't know. It doesn't sound easy to implement the guarantee, but maybe
it is. I am not a Blink/rendering engine internals expert.


> > Basically, my argument is that the con — that a general purpose
> > filtering HTML parser would be useful — is huge, and also
> > sufficiently covers your intended goal (duct-taping an anti-pattern).
> > Thus, if we do anything, we should do that.
> Mmm, I lost you here...  How is that a con?  It sounds like just an
> assertion, and one that I wouldn't argue with.  And my intended goal
> is not to get rid of innerHTML, but I'm happy to help by removing
> innerHTML the design pattern I originally suggested.
>
>
You listed it as the sole con:

Cons (relative to sanitization)
> 1) Being able to get sanitized markup is a feature that could have
> non-niche use cases that have yet to be identified.