Sanitizer specification
mozfreddyb opened this issue · 10 comments
Request for Mozilla Position on an Emerging Web Specification
- Specification Title: Sanitize Untrusted HTML
- Specification or proposal URL: https://github.com/WICG/purification
- Caniuse.com URL (optional): N/A
- Bugzilla URL (optional): N/A
- Mozillians who can provide input (optional): @ckerschb, @dveditz,
Other information
NB: This is an early stage exploration. @marcoscaceres suggested I file this, so here we go.
XSS (and lately, DOM XSS) is an ongoing struggle for web application developers - increasingly with the rise of so-called Single Page Applications.
We think there's value in getting a simple, single use-case API into browsers, that helps developers avoid brittle JS solutions, which suffer from DOM clobbering and cross-browser ambiguities. For more, please refer to the explainer doc.
@hsivonen may have thoughts on this, as the author of Gecko's built-in sanitizer.
I'd like to understand what use case the proposed single-use-case API would address. That part is not clear to me from the explainer. If we're going to go for simple and non-configurable then the hard part is hitting the right tradeoff between safety and usefulness...
Given the success of existing approaches in JavaScript libraries, I'm not too concerned about usefulness. Typical use cases are rich text editors, webmailers and forums that want to allow a subset of HTML. This will subset will be configurable.
Let me know if the explainer is glancing over some other interesting details and I'm happy to expand on that.
This will subset will be configurable.
Sure, if the subset is configurable then this is likely to be more useful; the question is how safe it is. Also, it seem to me that a configurable whitelist is not the "single use case" API that #106 (comment) talks about... I do see that the whitelist is configurable in the "Sanitizer Specification 1.0" in the roadmap in the explainer, though. How is this expected to work in practice? Will there be several different conceptual sanitizer uses and the browser picks the right whitelist for each one? Something else?
Basically trying to understand what the actual proposal is here, to the extent that we know these things already.
The user of the API will be able to provide options that remove or add specific elements from the built-in whitelist. They can also provide their own full whitelist. Same for attributes.
We're closely looking at DOMPurify options for inspiration - but we're not looking at hacks that are specific to a particular JavaScript libraries.
OK. To be clear, I consider pages overriding the whitelist a security footgun. The whitelist in browsers is subject to change as new capabilities are added to the web platform, and page whitelists would likely not get updated in that situation...
There's a footgun, I agree. My hope, of course, is, that people would supply a stricter whitelist, to only allow, say strong and em in their forum
But we also need to find a way for developers to add their Custom Elements to the whitelist. The only alternative I see is doing so implicitly within the API. But it seems more risky, as it prevents the developer form making a conscious security decision.
Adding custom elements to the whitelist seems fine; we can restrict such addition to valid custom element names...
It seems like there could be multiple mechanisms for providing configuration:
- replace the whitelist
- intersect with (i.e., subset) the whitelist
- remove particular elements from the whitelist
- add particular elements (e.g., custom elements) to the whitelist.
If there's risk that browsers may remove elements from the whitelist in the future, then the first two might be different.
In any case, this does sound like something useful, since it's something (a) for which there exist libraries but (b) that the browser could do better and (c) that's important to web security. So given that, and the fact that folks at Mozilla (@mozfreddyb) are in fact working on the spec, it seems reasonable to label it as worth prototyping.
(Once WICG/sanitizer-api#3 is merged I think this will be easier to auto-import.)
FYI, this is getting traction again. We've renamed it to Sanitizer API. An intent to prototype will be sent to dev-platform soon.