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

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:03:55 UTC