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

> Do I understand correctly that the motivation behind this proposal is to enable people to assign to someElement.innerHTML?
I was thinking about the innerHTML usage as just a means to an end.
The goal is to be able to give web apps a way to make use of untrusted
markup in a safe way.  The way this is achieved today is with a
sanitizer.  There was an initial conversation about building
sanitization into the browser, and my suggestion was that if we're
thinking about doing that for any reason, perhaps Safe Node would be
more sensible.

You're right that .innerHTML is an anti-pattern and maybe our best bet
is to avoid that syntax.  You could imagine a simplification of my
suggested syntax that rolls everything into one single
document.createSafeNode() method.

> 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.

> element.innerHTML = purify(untrustworthyString, options...)
> That seems convenient enough for callers?
See the pros / cons in my writeup.  And wait, didn't you just argue
that we shouldn't make use of .innerHTML given it's an anti-pattern?
=)

Dave

On Fri, Jan 22, 2016 at 12:35 PM, Chris Palmer <palmer@google.com> wrote:
> Do I understand correctly that the motivation behind this proposal is to
> enable people to assign to someElement.innerHTML?
>
> If so, why is it a goal to enable a well-known anti-pattern? If not, ignore
> the rest of this message. :)
>
> It reminds me a bit of efforts to make 'safe' string
> concatenation/interpolation APIs to stop SQL injection, in a world where
> parameterized queries already exist (and often execute faster). Here, we
> already have document.createElement, document.createTextNode,
> <element>.appendChild, and so on.
>
> In general, enabling well-known anti-patterns seems like a bad idea,
> especially when they seem to require magic to implement. For example, what
> is the actual mechanism/algorith/heuristic thsi API would use to enforce the
> Safe CSS set of policies?
>
>> * Safe CSS
>>  + Prevent anti-XSRF nonce theft via CSS
>>  + Prevent UI overlay
>>  + Prevent any identified abuse of existing styles on the page
>>  + Prevent styles defined within the Safe Node from affecting the
>> surrounding page
>
>
> Since the usual (reasonable) objection to document.createElement,
> document.createTextNode, <element>.appendChild, is that it results in
> verbose, blargy code, I'd rather see an API that makes use of techniques
> like this
> https://developer.mozilla.org/en-US/Add-ons/Code_snippets/HTML_to_DOM —
> filtering parsers. Basically, Cure53's DOMPurify, only standardized and
> built into the browser and implemented in native code. That way people could
> do
>
>     element.innerHTML = purify(untrustworthyString, options...)
>
> That seems convenient enough for callers?

Received on Friday, 22 January 2016 21:01:25 UTC