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

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

> For example, what is the actual mechanism/algorith/heuristic thsi API
> would use to enforce the Safe CSS set of policies?
> My argument is that it's smarter to implement policy enforcement
> within Blink / WebKit than it is to implement the same thing reliably
> within custom sanitizer code stapled onto Blink / WebKit.  For
> example, consider the case of the policy that disables script.  The
> browser can quite definitively disable script execution initiated from
> within a particular DOM node.  However a sanitizer has to whitelist
> all the elements and attributes it suspects are capable of initiating
> script execution.  Pushing the policy enforcement to be implemented
> close to the code that is being regulated makes it less likely that
> new browser features will subvert the policy enforcement.  Some things
> that are simply difficult or impossible for sanitizers to regulate in
> a granular way (eg: CSS) are easier to handle with a Safe Node.
>

That doesn't answer the question. 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.


> > element.innerHTML = purify(untrustworthyString, options...)
> > That seems convenient enough for callers?
> See the pros / cons in my writeup.


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.

But I remain skeptical of the goal.


> And wait, didn't you just argue
> that we shouldn't make use of .innerHTML given it's an anti-pattern?
> =)
>

I would rather deprecate innerHTML, yes. But at least I can easily grep for
"assigns to innerHTML but there is no call to purify(...)".