Re: In-browser sanitization first, "Safe Node" later?

fwiw, we use DOMpurify and its great. But its really tricky and painful to
get right
<http://www.slideshare.net/x00mario/in-the-dom-no-one-will-hear-you-scream>.
While I don't want to put words into Mario's mouth, I believe, Mario, the
creator of DOMPurify is one of the people arguing _for_ the "safe node"
that we have been talking about. See
https://www.usenix.org/sites/default/files/conference/protected-files/enigma16_slides_heiderich.pdf


cheers
Dev

On 8 February 2016 at 14:40, Jim Manico <jim.manico@owasp.org> wrote:

> How brilliant. DOMPurify is exactly the kind of tool that most developers
> need, IMO.
>
> * Conversion from bad HTML to good HTML in the browser via JS
> * Trivial to use library out of the box with no configuration
> * Lots of straight-forward configuration options (see the section on " Can
> I configure it?")
> * Easy to use to retrofit old apps (simple defensive paradigm)
> * Plays well with other libs and frameworks
>
> Thanks for pointing this out, Craig.
>
> Aloha,
> Jim
>
>
> On 2/8/16 12:03 PM, Craig Francis wrote:
>
> I've not had a proper look at this yet (reading on a mobile phone), but by sheer coincidence a very similar discussion/presentation covers this as well:
> https://www.usenix.org/conference/enigma2016/conference-program/presentation/heiderich
>
> Slides:
> https://www.usenix.org/sites/default/files/conference/protected-files/enigma16_slides_heiderich.pdf
>
> This is based on toStaticHTML(), which is available primarily in MSIE (slide 25).
>
> I must confess I've not seen/played with this API before, but may also serve as inspiration? along with the authors implementation:
> https://github.com/cure53/DOMPurify
>
> Craig
>
>
>
>
> On 8 Feb 2016, at 20:27, Devdatta Akhawe <dev.akhawe@gmail.com> <dev.akhawe@gmail.com> wrote:
>
>
> FWIW, the vast majority of XSSes that we see have to do with the
> failure to consistently call existing APIs for everything that needs
> scrubbing / sanitization. It's not a scientific number, but I'd say
> it's in the ballpark of 95%.
>
> That's why I'm a lot more inclined to believe that flexible
> containment solutions - such as Safe Node, suborigins, or some of the
> more recent evolutions of CSP - have more promise. Doubly so when they
> can be retrofitted cleanly and easily into existing software.
>
> +1 to both these points.
>
>
> =Dev
>
>
>