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

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

From: Craig Francis <craig.francis@gmail.com>
Date: Mon, 8 Feb 2016 22:03:25 +0000
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: <5404B7FE-D27D-4411-AF9D-AB56F1C629E6@gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
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

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