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 12:35:25 -0800
Message-ID: <CAOuvq20tao-cmJmXe8wGbj4_w2pvig6ngD1iOE56kVvwG+DVDQ@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>
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 20:35:55 UTC

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