W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

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

From: Jim Manico <jim.manico@owasp.org>
Date: Mon, 8 Feb 2016 12:40:51 -1000
To: Craig Francis <craig.francis@gmail.com>, Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Michal Zalewski <lcamtuf@coredump.cx>, Chris Palmer <palmer@google.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <56B91973.70302@owasp.org>
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.


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> 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
Received on Monday, 8 February 2016 22:41:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC