Intent to prototype: Sanitizer API

[Frederik Braun]

Hi all,


*Summary*:
We would like to expose a sanitizer API that accepts "bad" HTML (string,
DocFragment) and returns a sanitized DocFragment, using a pre-defined
list of allowed elements / attributes. The implementation is using code
that we have had in mozilla-central for a long while: The existing
nsTreeSanitizer is widely used (e.g., when pasting HTML into a document
or in Reader Mode). We believe that exposing this will be useful for
applications that want to protect themselves from XSS while allowing a
subset of HTML.

*Bug*: <https://bugzilla.mozilla.org/show_bug.cgi?id=1650370>

Standard: Still just a WICG draft at <https://github.com/WICG/sanitizer-api>

*Platform coverage*: All supported platforms.

*Preference*: Requires dom.security.sanitizer.enabled to be true

*DevTools bug*: <https://bugzilla.mozilla.org/show_bug.cgi?id=1652671>

*Other browsers*: Blink is prototyping, see
<https://groups.google.com/a/chromium.org/g/blink-dev/c/MJxVZs1H5SY/m/6q0QxEFtBAAJ>


*web-platform-tests*: WPT will be the primary test suite. However, we'll
keep a small mochitest in central for easier testing while we experiment
with API details and the final WebIDL. This will allow us to test things
independently, before we reach consensus. We expect the mochitests to be
fully replaced before this is exposed by default.

*Secure contexts*: Yes, required.

*Is this feature enabled by default in sandboxed iframes?*
This API is exposed via JavaScript, which sandboxed iframes do not
allow. Sandboxed iframes with "allow-script" will be able to make use of
this API.

*Link to standards-positions discussion*: worth prototyping
(<https://github.com/mozilla/standards-positions/pull/395>)

*How stable is the spec*: The API is getting stabler, but there are lots
of open questions when it comes to what ought to be allowed by default.
Concerns with forward/backward compatibility are not yet completely
resolved. Even with a list of safe HTML elements, script gadget attacks
need to be taken into account
(https://raw.githubusercontent.com/google/security-research-pocs/master/script-gadgets/ccs_gadgets.pdf).

*Security & Privacy Concerns*: This API does not expose information
about the user, their system or session. Some security questions
regarding compatibility have not been fully answered though. See note above.

*Web designer / developer use-cases*: Implementations as JavaScript
libraries exist, e.g., DOMPurify. However these implementations face
significant challenges: 1) Walking an attacker-controlled DOM tree is
extremely challenging. The page at
<https://portswigger.net/web-security/dom-based/dom-clobbering> gives an
example of DOM clobbering attacks, in which elements with id="attribute"
can shadow the parent element's "attribute" property. 2) Parsing
ambiguities between security library and browser can lad to security
bugs. We're hoping that an implementation which matches the browser's
parsing behavior will eradicate this issue. In essence: We know
thatframeworks and single-page applications already make use of this
feature, but we hope to provide a better level of security that can
overcome the problems that a JS implementation has to face.

*Example*:
```
mySanitizer = new Sanitizer(/* some options *);
mySanitizer.sanitize("<p>hello!<script>alert('oops');</script></p>);
// returns DocumentFragment [ <p>hello!</p> ]
```


Kind regards,
Freddy