Consider metadata API; building blocks for HTML sanitizers

[xtofian]

Browser-side HTML sanitizers are typically implemented by

• parsing HTML into an inert Document(Fragment)
• transforming the resulting "untrusted" tree into a safe tree, by pruning or copying based on attribute/element white/black-lists.
• re-serializing the tree into HTML (not necessary if the "clean" tree can be directly attached to the DOM).

Examples: https://google.github.io/closure-library/api/goog.html.sanitizer.HtmlSanitizer.html, https://github.com/cure53/DOMPurify.

The necessary whitelists are a fairly significant part of the sanitizer's code size (blacklists would be smaller, but blacklists are generally brittle); https://github.com/cure53/DOMPurify/blob/master/src/attrs.js, https://github.com/cure53/DOMPurify/blob/master/src/tags.js, https://github.com/google/closure-library/blob/master/closure/goog/html/sanitizer/attributewhitelist.js, https://github.com/google/closure-library/blob/master/closure/goog/html/sanitizer/tagwhitelist.js

TT introduces implicit knowledge into the DOM API of the security semantics of DOM attributes. It seems worth considering if we can expose this information somehow, so that it can be used to as the basis of a HTML sanitizer's policy, which could then avoid the code size overhead of their own metadata tables.

Caveat: This will likely not obviate the need for sanitizer-specific whitelists/blacklists altogether: There are elements whose attributes don't require sanitization in a typical application's threat model (where the presence of the element in the DOM is application controlled, and only the attribute's value is potentially malicious); while the entire element is undesirable to keep when sanitizing entirely-untrusted HTML markup. E.g., <form> comes to mind.

[koto]

This is discussed under WICG/sanitizer-api#1.

[koto]

Apart from minimizing the code of the sanitizers, the metadata might be helpful for other libraries. For example, Angular compiles the template (in AOT mode at build time) that later on are serialized to a series of definitions based on strings. Later on, these strings are serialized into DOM using wrappers over createElement and setAttribute calls here:

https://github.com/angular/angular/blob/master/packages/core/src/view/element.ts#L151

Since in Angular AOT the template itself cannot be influenced by the attacker, this DOM serialization is safe, however to satisfy Trusted Types contract, various TT objects need to be created near the sink there, so this class needs to ship the element,attr->trusted type mapping to be compliant (and keep it in sync with the DOM type requirements for a given browser). cc @otherdaniel @xtofian

[koto]

I noticed that the same behavior affects DOMPurify here.

[koto]

I created a first draft of the API in #149 , I'm still not sure about its shape.

This API is useful for migrating existing codebases (to be consumed by DOM builder libraries e.g. in sanitizers to know which type to create when calling setAttribute or setting properties).

The minimal possible shape should be just the getTypeMapping(namespaceURI) function, but the resulting map contains a * entry that should be defaulted to when a given element/tag is not listed (that is how innerHTML property is required, without having to list all possible tag names).

get(Property|Attribute)Type help with resolving the type when an element is known, applying the aforementioned fallback.

I decided to key by the tag names vs the element constructor names, also tag name is uppercased, whereas attribute name is lowercased, but I don't have strong opinions here.

What will follow is the spec change to incorporate that, but please take a look at the draft implementation, so we don't spec & implement an awful API. @otherdaniel @sebmarkbage @mikesamuel.

[xtofian]

This generally seems a reasonable API.  One thing that comes to mind is how the 
// TODO(koto): Figure out what to to with <link> (and possible other dependently-typed situations where the type of the attribute depends on the value of another attribute) would influence the shape of the API.

getAttributeType('link', 'href') could return 'ItsComplicated' to indicate that ad-hoc code needs to deal with this situation. This seems like a kludge. Or, getAttributeType could take the specific element as an argument and look at the run-time value of rel to figure out which type is required; but that'd be a very different API.

IOW, it might be time to resolve #6...

[xtofian]

Aside: Once getAttributeType is specified, it would be a more precise way to express the "expectedType" table in https://wicg.github.io/trusted-types/dist/spec/#enforce-a-trusted-type-algorithm.

[koto]

I commented on #6, but I don't think this should be a blocker for the metadata API (we can even return multiple types per attribute if needed). #6 will likely be resolved by changing the type required to the most restricting one, I don't think we should mutate the type based on another attribute value, this is messy.