How to handle <template>?

[xtofian]

Client-side templating systems (such as polymer, angular, knockoutjs, etc) generally make the assumption that the elements and attributes that make up a template are trustworthy. This is primarily because contents and attributes elements underneath templates may contain template expressions, which are evaluated as code (see e.g., https://angular.io/guide/security#angulars-cross-site-scripting-security-model -- Angular happens to not use <template> but is the one template system that actually documents this assumption).

Thus, while el.textContent = untrusted is generally harmless, it is a potential vulnerability if el is a child/grandchild of HTMLTemplateElement.

It's not clear what set of types make sense for element contents/attributes of children of a <template>; I suspect this depends on the semantics of the template system / framework that interprets them. Furthermore, it seems generally undesirable for frameworks/application to rely on runtime-manipulation of templates (it's indicative that many such frameworks suggest use of a compilation step for production deployments, e.g., https://www.polymer-project.org/2.0/toolbox/build-for-production, https://angular.io/guide/security#offline-template-compiler).

With that in mind, it might make sense to simply make children/grandchildren of HTMLTemplateElement completely unmodifiable?

[xtofian]

Related: are there other cases where the type of an element's parent/grandparent affects the security contracts of its contents/attributes? E.g. is it possibly for there to be a tree of nodes underneath a HTMLScriptElement?

[koto]

There are templating systems that mutate TemplateElement dynamically, similarly some client-side sanitizers operate on a mutable TemplateElement as an inert container.

[koto]

are there other cases where the type of an element's parent/grandparent affects the security contracts of its contents/attributes

Generalizing, yes. As long as the application reads from the DOM, and then makes the security decisions based on the read result, one can have vulnerabilities based on any DOM structure that would match the DOM fetching criteria (a la script gadgets).

E.g. is it possibly for there to be a tree of nodes underneath a HTMLScriptElement?

Yes, #133 demonstrates this. For JavaScript scripts, only text nodes and only present before a <script> is inserted into the DOM will execute, but this is irrelevant for scripts used as data blocks.

Both template and script are script supporting elements, so there is a spec term we could hook into to restrict the behaviour. However it does increase the complexity of the implementation quite a bit (effectively we'd need to taint-track nodes, as those can be moved around). We are doing that to some extent in https://chromium-review.googlesource.com/c/chromium/src/+/1547746, but that's only for direct descendant text nodes in scripts, and it's possible because it's a virtually non-existent pattern that is a bypass resulting in direct (i.e. non-application-specific) JS execution, whereas templates vulns would be second order XSSes (or gadgets).

[koto]

Closing for now.