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