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

Thank you Michal. I'll give David's proposal a closer read and comment 
shortly.

I remember Microsoft and their AntiXSS library providing an HTML 
Sanitizer API for untrusted HTML input. It was one of the first in any 
major language or framework. The first version was very permissive and 
useful but unfortunately was vulnerable to HTML hacking and of course 
XSS. The latest incarnation was fixed to be very secure, but 
unfortunately was not at all useful because it was so restrictive. And 
MS is now deprecating it with no commitment to maintain it.

I have an aversion to different policy packages not being flexible 
enough to be useful. But I will give David's proposal a deeper read and 
provide comments more specific to his proposal.

Perhaps support both of these approaches? HTML Programmatic sanitization 
and several pre-built policies? That would provide both easy of use for 
some, and deep flexibility for others. Win win win, and win?

Aloha,
Jim


On 1/22/16 5:29 PM, Michal Zalewski wrote:
>> 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:41:13 UTC