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

> Is my concern that your policy-sandbox would need constant
> updating as new browser features were added a fair concern?
Any sanitizer needs some ongoing level maintenance already today.  A
lot of that is just to add support for (whitelist) new browser
features, and then to backtrack a bit if that turns out not to have
been such a good idea.  =)  When you've got a sanitizer written in C++
and baked into a browser, updating that sanitizer in this way might be
even more burdensome.

In the case of Safe Node, we would _not_ generally make one-off
changes to tweak the code to add or remove support for new elements,
attributes, etc.  Adding any new feature, the question would be this:
Walking down the list of Safe Node enforced policies, would the new
feature subvert any of them?  If so _and_ the new feature doesn't
leverage existing building blocks that are already regulated by
policy, _then_ there needs to be additional policy enforcement put in
place.  So I think that an implementation of Safe Node would require
less ongoing maintenance than a sanitizer baked into the browser.

> Do you think supporting some kind of HTML policy engine like
> I'm suggesting is valid at all?
Can you get a little more specific about what you're suggesting?

Dave

On Fri, Jan 22, 2016 at 4:43 PM, Jim Manico <jim.manico@owasp.org> wrote:
>> and certainly it's no more blacklist-based than a sanitizer
>
> Hmmm. My thinking was "Davids proposal is going to disable certain features.
> HTML sanitizers only try to enforce good tags without needing any knowledge
> of the bad stuff". That is why I think of your work as "blacklist" and HTML
> sanitizers as "whitelist".
>
> Anyhow, it sure was an Edge-ie case! Thank you for catching my lame pun. I
> know this is going to hurt you to hear it, but IE and Edge matter. I'm glad
> to know your proposal would have caught this.
>
> Is my concern that your policy-sandbox would need constant updating as new
> browser features were added a fair concern?
>
> Do you think supporting some kind of HTML policy engine like I'm suggesting
> is valid at all?
>
> Aloha,
> Jim
>
>
>
>
> On 1/22/16 6:35 PM, David Ross wrote:
>
> I would not characterize it as blacklist-based, and certainly it's no more
> blacklist-based than a sanitizer.
>
>> What about CSS expressions and other edge cases not
>> described in http://lcamtuf.coredump.cx/postxss/ ?
> It's covered by this policy:
> * Disablement of script / active content
>
> Also, was that a pun?  Because CSS expressions are an Edge case.  =)
>
>
> On Fri, Jan 22, 2016 at 3:28 PM, Jim Manico <jim.manico@owasp.org> wrote:
>>
>> 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 Saturday, 23 January 2016 01:04:43 UTC