1 of 7

Identifying Literals

Mike West, Adam Klein (Google)

November 2017, TC39�

Slides: https://goo.gl/p2Wi9f

Proposal: https://github.com/mikewest/tc39-proposal-literals

2 of 7

XSS is, in part, a string problem.

The web’s APIs are riddled with methods/attributes which accept string inputs, compile them, and execute them as script.

el.innerHTML = …

scriptEl.innerText = ....

a.onclick = …

location.href = …

// And on and on and on...

3 of 7

Type checking can mitigate.

See Christoph Kern’s

“Securing the Tangled Web”

4 of 7

“Trusted Types”

is a proposal which aims to bring opt-in type-checking mechanisms to DOM APIs.

let a = “https://a.test/”;�

// Throws!

location.href = a;�

// Succeeds!

let url = TrustedUrl.create(a);

location.href = url;

5 of 7

Google’s experience

shows that distinguishing strings embedded directly in program code substantially reduces security review overhead.

let a = "https://a.test/";�

// Google’s compiler disallows:

let url =

goog.string.Const.from(a);

// While allowing:

let url = goog.string.Const

.from("https://a.test/");�

// Only accepts a `Const`:

SafeUrl.fromConstant(url);

6 of 7

Can we have this kind of check on the web?

7 of 7

Handwavey proposal:

Brand template literals (e.g. via a [[TemplateLiteral]] internal slot) in GetTemplateObject. Built-in web APIs can check that brand before execution.

// Returns a `TrustedUrl` object:

TrustedUrl

.fromLiteral`https://a.test/`;

​

// Throws a TypeError:

TrustedUrl

.fromLiteral(el.value);