Add keyword to prevent parser-based JS APIs from adding new scripts

[arturjanc]

Context
whatwg/html#2300 (particularly the comment thread)
https://codereview.chromium.org/2657623005

Summary
Let's add a new script-src keyword ('safe-dynamic-markup') which will prevent the execution of scripts added to the DOM via a parser-pased JS API (Element.innerHTML, document.write, etc). When a new script element is added, the user-agent should check if its parser-inserted flag is set, and if the element has been added via a JS API, and if both conditions are met and the 'safe-dynamic-markup' keyword is specified, block the execution of the script and report a violation.

To be effective, this also has to apply to scripts inside frames which inherit the policy of the embedding page (iframe#srcdoc).

Background
There are three main kinds of DOM APIs which lead to DOM XSS bugs:

• eval() & co. which directly execute scripts based on their arguments
• window.open(), assignments to location.href, etc which allow script execution via javascript: URIs.
• Parser-based APIs such as innerHTML, document.write and related functions.

CSP already mitigates the first two types (via a policy without 'unsafe-eval' and 'unsafe-inline' respectively), and it prevents the execution of inline event handlers ('onclick', etc) if an injection into a parser-based API happens. However, an injection into such an API can still lead to script execution: in whitelist-based CSP, if the policy contains a domain with a "bypassable endpoint" (e.g. a JSONP endpoint or a hosted copy of AngularJS) an attacker will be able to source it as a script (<iframe srcdoc='<script src=//cdn.org/angular.js></script>'></iframe> and bypass the policy; in a nonce-based policy, an attacker who exfiltrates the nonce via dangling markup or another technique will be able to use the stolen nonce (<iframe srcdoc='<script nonce=[stolen]>alert()</script>'></iframe>).

If we allow developers to block the execution of all scripts added via parser-based JS APIs, it will get us fairly close to preventing the exploitation of DOM XSS via native platform APIs (though some JS libraries might still open up their own new attack vectors).

Compatibility
In a lucky turn of events, many applications with a useful CSP (without 'unsafe-inline') are already compatible with the proposed keyword because adding new script elements at runtime usually happens via programmatic APIs (createElement('script')). The patterns which would need to be refactored are:

• document.write("<script>...") -- would need to be refactored to use programmatic APIs.
• element.innerHTML = "<iframe srcdoc='<script …>'></iframe>" -- as above, but this a rare pattern. Note that a direct assignment of <script>...</script> to innerHTML is not a problem because this doesn't execute scripts as discussed in <iframe srcdoc="<script>"> should not execute when inserted via innerHTML. whatwg/html#2300.

Overall it seems like it could be a useful defense-in-depth against DOM XSS bugs and bypasses of CSP, with a reasonably high chance of being adoptable in many applications without significant effort.

[annevk]

What about the <iframe> with data or javascript URL scenario mentioned in the HTML Standard issue?

[arturjanc]

Anne, I assume you're asking what should happen to scripts in such frames if the new keyword is set?

These two patterns shouldn't be a problem: javascript URIs are already blocked by CSP so <iframe src="javascript:"> will be prevented from executing, regardless of the new keyword. <iframe src="data:"> is a frame from a unique origin which doesn't inherit the policy from the parent so it also shouldn't be affected (we should only prevent script execution in same-origin frames which inherit the policy -- this is how an attacker would attempt to bypass the policy if they have an injection).

I believe the main cases where frames inherit their parent's policy are iframe#srcdoc, iframe#src=about:blank and iframes without a src. In general, we should be able to treat them all like the srcdoc case (don't execute any scripts in such frames if the scripts were added via a parser-based API).

There are certainly applications which document.write() blobs of HTML, including scripts, into such iframes -- they would need to be refactored to add scripts to the frame via createElement('script') instead.

[annevk]

If you can inject a data URL <iframe> you can still postMessage() to the parent and potentially attack it through that. You can also navigate the parent though I suppose CSP might block that.

[arturjanc]

You're right, but it's orthogonal to this proposal -- it doesn't attempt to restrict framing, but to prevent script execution, which is why I suggested it as part of script-src. An attacker with a markup injection bug can use it to insert arbitrary iframes into the vulnerable document, and they can do the things you mentioned, but this is much less powerful than script execution in the context of the vulnerable origin.

Frames are part of the HTML spec discussion because attackers with a DOM XSS can inject their own iframe#srcdoc with evil markup, which is same-origin with the embedding document (unlike data: URI iframes -- at least according to the spec ;-). To be successful at preventing script execution in the context of the vulnerable origin we have to guarantee that in code such as
foo.innerHTML = "<XSS /> <iframe srcdoc='<script>alert(document.domain)</script>'></iframe>"
the script element inside the frame is treated as parser-inserted and that we can track that it was created as a result of executing a JS API.

If we can do this, we can ensure that injections into parser-based APIs (the most common kind of DOM XSS) do not allow attackers to trigger arbitrary JS execution in the vulnerable origin.

[Jamesernator]

This is definitely something I'd like to see, currently strict-dynamic is too difficult to set up in most cases for a static site as lots of common tooling don't support generating hashes and nonces are unusuable altogether on a statically hosted site. Host-based rules doesn't quite work either as if you want to load packages from an npm CDN, then simply whitelisting the CDN is not safe as anyone could just upload a malicious package to npm and hence it'd be available from the CDN.

This rule suggestion would pretty much solve that problem though as I could just just shove <meta http-equiv="Content-Security-Policy" content="script-src safe-dynamic-markup"/> into the static pages and not be worried that there are places where .innerHTML might insert a script.

And it integrates particularly well with ESM, as for CDN resources or whatever, well any static imports could just be trusted i.e.:

<!-- In the original markup so trusted -->
<script type="module">
    // Also trusted as it's loaded statically from the markup
    import somePackage from "https://some.cdn/npm-package/main.js";
</script>

It'd be nice to integrate with dynamic import somehow though as async chunk loading is fairly popular. If we had a way to declare certain urls as safe statically for dynamic importing then we could load them later. Possibly we could treat ones declared in the import map as trusted or something?