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

>From Crispin:
> So, what if CSP 3 were to start working per-node instead of per
> page? Take the existing mechanism that's working and generalize
> it a bit so that it addresses the problem of wanting to safely insert
> some foreign markup here and there.
>
> Why I'm suggesting this: to make solutions that are easy to use,
> I try to pretend that I'm not very smart. Some might say I don't
> have to try very hard :)
>
> Potential response: maybe this is effectively what David is
> proposing?

Yeah, pretty much.  =)  I agree it's a noble goal to make the syntax
as compatible with CSP as possible for the reason you suggest.

On Fri, Jan 22, 2016 at 2:29 PM, Michal Zalewski <lcamtuf@coredump.cx> 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:35:44 UTC