[templates] Contextual auto-escaping

[justinfagnani]

With the removal of replaceHTML(), and if replace() performs escaping like setting textContent the design of template system should be fairly secure (pending actual security reviews).

One place it could be better is by adding contextual auto-escaping to prevent user-provided values from executing script when used in dangerous attributes, like with:

<a href="{{url}}">{{title}}</a>

template.createInstance({
  url: 'javascript:alert("hi")',
  title: 'XSS',
});

[bkardell]

Are you suggesting that it would automatically do appropriate safe escaping based on where it appears (an attribute, some text, a link, etc)?

[justinfagnani]

Yes. My understanding of Contextual Autoescaping is pretty cursory (I've been asked to look into it tfor lit-html), but from what I understand there's a blacklist of certain attributes on built-in elements that must be escaped. The only way to avoid escaping is by providing a safe/trusted value type, like proposed here: https://github.com/WICG/trusted-types

[xtofian]

Other examples of (strict) contextual auto-escaping/sanitization:

• Angular: https://angular.io/guide/security#angulars-cross-site-scripting-security-model (or https://docs.angularjs.org/api/ng/service/$sce for Angular 1.x)

• Polymer-resin (https://github.com/Polymer/polymer-resin), an add-on for Polymer that enables contextual escaping in Polymer templates.

• Closure templates (https://developers.google.com/closure/templates/docs/security)

For an example of a specification of HTML attributes with security-sensitive contexts, see the one in Polymer-resin, https://github.com/Polymer/polymer-resin/blob/master/lib/contracts/contracts.js.

Note that this is a whitelist, and is incomplete (we're just adding attributes to the whitelist as they're needed and are getting reviewed for their security implications).

A very valuable side contribution of adding contextually autoescaped templating to the web-platform (as well as the TrustedTypes proposal, which is about mediating injection sinks in the DOM API; the two largely correspond), would be to publish a comprehensive specification of the security properties (in the sense of whether they're an injection sink, and of what kind) of all HTML attributes and DOM properties.

It could be quite desirable to expose this meta data somewhere in the DOM (e.g. as read-only window.security.html.... and window.security.dom... objects similar to what's in https://github.com/Polymer/polymer-resin/blob/master/lib/contracts/contracts.js, but comprehensive and vetted and maintained by HTML spec authors). This would be useful for various other HTML templating systems (that may not be able to use the templating mechanism proposed here, but would want to use the same sanitization policies).

For more background on how the strict contextually auto-escaping/sanitizing template systems go together with safe/trusted types, see https://research.google.com/pubs/archive/42934.pdf

[rniwa]

This is about the default template processor, right?

[justinfagnani]

@rniwa yes, although sliced right we could offer utilities to other processors so they can implement auto-escaping properly themselves.

Also, we could consider speccing the template parts value setters to be safe by default so that all processors are safe.