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

> The need to inject untrusted markup into the DOM comes up all the time and
> is critical (WYSIWYG editors ,etc). But any "safe node" that limits what can
> render and execute will limit innovation. Each developer needs to support a
> different markup subset for their app, which is why policy based
> sanitization is so critical to this use case.
>
> Take a look at CAJA JS's sanitizer, Angulars $sanitize,  and other JS
> centric HTML sanitizers. They all allow the developer to set a policy of
> what tags and attributes should be supported, and all other markup gets
> stripped out.
>
> This is the kind of native defensive pattern we need in JavaScript, IMO!

I think there are interesting trade-offs, and I wouldn't be too quick
to praise one approach over the other. If you design use-centric
"policy packages" (akin to what's captured in David's proposal), you
offer safe and consistent choices to developers. The big unknown is
whether the policies will be sufficiently flexible and future-proof -
for example, will there be some next-gen communication app that
requires a paradigm completely different from discussion forums or
e-mail?

There is a handful of examples where the rigidity basically ruled out
adoption (e.g., MSIE's old <iframe> sandbox).

The other alternative is the Lego-style policy building approach taken
with CSP. Out of the countless number of CSP policies you can create,
most will have inconsistent or self-defeating security properties, and
building watertight ones requires a fair amount of expertise. Indeed,
most CSP deployments we see today probably don't provide much in term
of security. But CSP is certainly a lot more flexible and future-proof
than the prepackaged approach.

At the same time treating flexibility as a goal in itself can lead to
absurd outcomes, too: a logical conclusion is to just provide
programmatic hooks for flexible, dynamic filtering of markup, instead
of any static, declarative policies. One frequently-cited approach
here was Microsoft's Mutation-Event Transforms [1], and I don't think
it was a step in the right direction (perhaps except as a finicky
building block for more developer-friendly sanitizers).

[1] http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/hotos07.pdf

Received on Friday, 22 January 2016 22:30:16 UTC