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

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

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Mon, 8 Feb 2016 11:39:57 -0800
Message-ID: <CALx_OUDx=p5RepOA8PLp6CB1+mMVc=QWUj2RLbYrVVvdTzYVkQ@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
Cc: Craig Francis <craig.francis@gmail.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> I also prefer The Simplest Thing That Could Possibly Work. To me that would
> seem to be the string in/string out interface, or a string in/tree of DOM
> Nodes interface (then the caller could do something like:
> e.appendChild(purify(bad_string)) ). Or both.

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

Failures in sanitizers are a very tiny fraction of all bugs, and the
proliferation of sanitizers often has to do with the fact that they
are often designed for different purposes (e.g., sanitization goals
for discussion forums, for blogs, for e-mail, and for ads may be very
different).

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.

/mz
Received on Monday, 8 February 2016 19:40:46 UTC

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