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:




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:



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