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

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

From: Jim Manico <jim.manico@owasp.org>
Date: Mon, 8 Feb 2016 09:26:08 -1000
To: Craig Francis <craig.francis@gmail.com>, Frederik Braun <fbraun@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <56B8EBD0.1080607@owasp.org>
 > 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 think this would be immensely valuable for existing developers building apps today. Craig is right, the list of safe JS Nodes/API's is complex but there is significant existing work in this area. It's also a fairly small list as most JS api's are inherently dangerous when populated with untrusted content.

So a nice catalog of safe JS API's (like setting a nodes value via .textContent) would be a solid win.

-
Aloha,
Jim


On 2/7/16 11:34 PM, Craig Francis wrote:
> As a web developer who frequently has to sanitise HTML (more so server side), I would still like to see this.
>
> But creating a safe node list will be difficult.
>
> Take the <a> as an example, imagine a forum with a WYSIWYG (/me shudders)... some forums won't like this at all (SEO spamming), some may consider this safe if it has a rel=nofollow... but many will forget the href="javascript:...", which is a valid attribute on a valid node, but getting a click event can cause inline JavaScript to run (assuming no CSP that blocks unsafe-inline).
>
> If you know how to solve this (both as a Sanitiser or under a Safe Node), then I'll be very happy.
>
> Craig
>
>
>
>> On 8 Feb 2016, at 08:48, Frederik Braun <fbraun@mozilla.com> wrote:
>>
>> 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 19:26:42 UTC

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