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

David,

I think your work on JSanity is excellent, but again it's a cat and 
mouse game that is hard to win. Even recently we see a significant 
evasion for JSanity https://github.com/Microsoft/JSanity/issues/6 that 
would not be a problem for a rule based HTML sanitizer.

I am not saying drop your proposal, I would just like to see 
programmatic, rule based sanitization in addition to generalized 
blacklist policies/sandboxes like you are suggesting.

Aloha,
Jim




On 1/22/16 6:17 PM, David Ross wrote:
>> There is a handful of examples where the rigidity basically
>> ruled out adoption (e.g., MSIE's old <iframe> sandbox).
> This: https://msdn.microsoft.com/en-us/library/ms534622(v=vs.85).aspx
> It came in for Hotmail, but it was never put to use AFAIK, exactly for
> the reason you describe.
>
> There is a finite list of "unsafe" things that markup / CSS can do
> when rendered on a page.  (Essential reference, of course:
> http://lcamtuf.coredump.cx/postxss/)  It is possible there are a
> couple things missing from the initial list of Safe Node policies
> requiring enforcement.  (E.g.: Link targeting is covered but we
> probably also need a way to regulate navigation more generally.)  But
> the problem is tractable.  And I don't think that sanitization baked
> into the browser provides a better approach in this regard.
>
> Another key thing here is that with either a sanitizer or Safe Node,
> it's important to pick a good set of secure defaults.  That way the
> policy problems Michal described are less likely to occur as custom
> configuration tends to be minimal.  With the sandbox attribute for
> frames, I think the use cases vary to such an extent that it would
> have been hard to set secure defaults.  E.g.: allow-scripts and
> allow-same-origin are OK independently, but not when combined.
> There's no safe default there because there are many use cases for
> either approach.  I don't see that Safe Node policies interfere with
> each other in this way and so we probably dodged this bullet.
>
> Jim said:
>> I have an aversion to different policy packages not being
>> flexible enough to be useful.
> FWIW, as per earlier in the thread, the Safe Node approach addresses
> scenarios around CSS where _sanitization_ is inflexible.  (Caveat: If
> a sanitizer is baked into the browser, all of a sudden it can pursue
> the same approach.)
>
>> 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?
> My argument is that Safe Node has advantages relative to sanitization
> baked into the browser.  If you can identify a legit use case that
> Safe Node can't support cleanly, but browser-based sanitization does,
> I'd probably jump right back on the sanitization bandwagon.  I wrote a
> client-side sanitizer not that long ago and I enjoy working on them.
> =)
>
> Dave
>
> On Fri, Jan 22, 2016 at 2:40 PM, Jim Manico <jim.manico@owasp.org> wrote:
>> 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 23:33:50 UTC