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> 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