W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

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

From: Chris Palmer <palmer@google.com>
Date: Fri, 22 Jan 2016 13:32:48 -0800
Message-ID: <CAOuvq23iy-oPcLrsfJo6BFswKod6bmgz7ju=wCgw=_YzK2+Z3g@mail.gmail.com>
To: David Ross <drx@google.com>
Cc: Craig Francis <craig.francis@gmail.com>, Conrad Irwin <conrad.irwin@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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(...)".
Received on Friday, 22 January 2016 21:33:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC