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

Again, I am reading your proposal right now, but this looks a little 
blacklist-ish to me. What about CSS expressions and other edge cases not 
described in http://lcamtuf.coredump.cx/postxss/ ? There more out there 
per my understanding....

This is why I prefer more programatic sanitization is because it's a 
whitelist which tends to be a stronger control. Once a good sanitization 
API is built, it will stand the test of time as new browser features are 
added.

An approach just banning bad things will be way more fragile as new 
browser features get added over time.

- 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:28:51 UTC