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

 > 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 inhttp://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 
> <mailto: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 <https://msdn.microsoft.com/en-us/library/ms534622%28v=vs.85%29.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 <mailto: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
>
>
>
>