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

Hi,

I think there is a need for a client-side HTML/XSS sanitization
mechanism that lives in the browser (i.e., where the parser is).
AFAIU, previous discussion has shown that there are no strong objections
to this, but feel free to look the previous thread [1] or Mario
Heiderich's presentation from Usenix Enigma [2] for further reading.

I think that a first version of this spec should be a JavaScript API
that consumes a string of potentially dangerous markup and returns a
string that is clean.

A Safe Node is certainly more interesting, but I'm afraid that we (the
working group) are sometimes too detached from the needs of a modern web
application and that we should start with providing something useful *soon*.
As we have seen with CSP, it's always harder to retrofit a new security
system to an existing architecture. But the "String In - String Out"
approach will certainly fit into every app. We can still do the Safe
Node in a follow-up, if the initial feedback is good.

Another outcome of the reduced first version would be a public, vetted
and testable whitelist of safe DOM Nodes. This is useful for all
existing custom sanitizers and is a positive outcome of its own [3].

I expect that this first version will be easy to implement, given that
existing browsers use already this internally, albeit not exposed to web
content.

In the long run, attackers might race towards finding and abusing parser
bugs and more quirks like those which Mario has called mXSS (mutation
XSS) [4]. This is good, as it will guide us to what a Safe Node will
need and prove that we have indeed risen the bar beyond trivial XSS
exploits.

Thoughts?


Cheers,
Frederik


[1] For the initial thread "In-browser sanitization vs. a “Safe Node” in
the DOM" see
https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/thread.html

[2] Link to his slides and the abstract at
https://www.usenix.org/conference/enigma2016/conference-program/presentation/heiderich

[3] Obsolete whitelist at WHATWG wiki:
https://wiki.whatwg.org/wiki/Sanitization_rules

[4] "mXSS Attacks: Attacking well-secured Web-Applications
by using innerHTML Mutations", see https://cure53.de/fp170.pdf

Received on Monday, 8 February 2016 08:49:04 UTC