Security

[justinfagnani]

There are number of important security concerns to address in Heximal.

At the very least:

1. Self-defining components and self-rendering templates with expressions can easily lead to gadget attacks
2. Documents that can execute arbitrary code in a browser environment can make same-origin fetches. When documents are user-authored, they must be untrusted, and isolated from other trusted and untrusted resources.

The current implementation of Heximal is definitely vulnerable in a few places. There are a few general approaches we can take to secure it:

1. Reduce auto-evaluation of expressions.

   Auto-templates (<template h-auto>) must already be enabled by a call to runAutoTemplates(), which is not live, so any new auto-templates are not run. This provides some protection against unsanitized attacker-controlled HTML containing templates. Declarative custom elements however can be defined an instantiated in an HTML-only payload. We could move to a system where custom elements will only be defined at the behest of script, so that late defined elements would not run automatically. We could also require a nonce on definitions to run them.

   A platform feature like being able to detect if an element was parser-inserted could help unsafe Heximal elements have script-like behavior, ie. not run when created from innerHTML, etc.

2. Vend a sanitizer that disallows Heximal template and custom element definitions.

3. Filter objects in the expression system to prevent accessing the global, object and function prototypes, etc.

4. Vend a validator to statically validate that documents are within a safe subset of HTML + Heximal.

For multi-document systems with untrusted authors, we have to assume that every document is also untrusted, and rely on the same-origin policy to secure them:

1. Vend a viewer elements that uses <iframe sandbox> to view documents and fails if the browser doesn't support sandbox.
2. Vend a server that can search each document from a unique origin.