Assigning location.href to a javascript:... is a form of eval

[dinofx]

Extracted per request in the discussion in #322.

Assigning location.href= to a string that starts with javascript: is a form of eval, similar to setTimeout(someString), and others. It should only execute if unsafe-eval is allowed. But currently in many browsers unsafe-inline will allow this dynamically constructed JavaScript to be evaluated. This is likely due to ambiguity in the spec.

What constitutes an "Inline" script is not well described in the spec. I think most would consider it to be scripts that appeared "in line" in the original HTML response. The reason such inline scripts might be unsafe is because a browser doesn't know if these scripts were dynamically constructed on the server, potentially using query params or other data an attacker would control (i.e. a reflection attack). When a page allows unsafe-inline, it's stating that such server-side attacks either don't apply, or have been considered and mitigated/sanitized on the backend.

Both of the following are an example of inline script:

<a href="javascript:alert(0)" >click me</a>
<div onclick="alert(0)"> click me</div>

In both of the above, the script executed, alert(0), was inline in the html returned from the server.

By contrast, consider these:

<script>
  location.href = 'javascript:' + malicious;
</script>
<div onclick="location.href = 'javascript:' + malicious" >
<div onclick="eval(malicious)" >

All of these should be blocked unless unsafe-eval is allowed. The importance difference is that the malicious script being executed is not inline. It may have been dynamically constructed in the browser, which is a much different threat than inline scripts originating from the server.

[annevk]

https://w3c.github.io/webappsec-csp/#directive-script-src seems pretty clear to me. And I doubt the corresponding algorithms would suggest anything different or be ambiguous in that manner. I also doubt this can be changed at this point.

What browsers are inconsistent on this? Do you have a test?

[dinofx]

From the link above:

6. Navigation to javascript: URLs MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?

"Navigation to javascript: URLS" is clear to me. "Clicking" on an anchor tag that has an inline script (i.e. an href with a javascript: URL) is what is meant here.

Whereas code that assigns location.href== 'javascript:' + malicious is NOT a navigation. When it comes to the "should block inline" algorithm, which starts off saying "Given an element, a string type, and a string source this algorithm returns Allowed ...", it doesn't apply. The script in this case did not originate from any element, because it isn't an inline script.

However, item 4. ("JavaScript execution sinks") fails to include location.href assignment to javascript urls, which probably forced some browser implementation to guess, and the rest just followed suit.

[dinofx]

I agree it will be a challenge to fix things, but the current state of things it is very misleading to web developers. Most developers will assume that unless they include unsafe-eval, they don't have to worry about arbitrary execution of javascript.

[annevk]

What do you mean is not a navigation? That's certainly a navigation.

[dinofx]

"3." Is talking about inline scripts that run automatically as the page is loaded.
"6." is talking about inline scripts that run when a user interacts with the page. "navigation" in this context means running the inline script as a result of clicking the element whose attribute contains an inline script.

For code doing location.href== 'javascript:' + malicious, where is the inline script that would make 6. relevant? If it's a "navigation", what events get fired associated with navigating?

[annevk]

"navigation" in this context means running the inline script as a result of clicking the element whose attribute contains an inline script.

What makes you say that? Navigation there refers to the concept of navigation as defined in the HTML Standard.

[dinofx]

What makes you say that? Navigation there refers to the concept of navigation as defined in the HTML Standard.

A javascript: url is referred to as a special case. A form of navigation only takes place when that script returns a non-null result (step 8).

But, back to the CSP spec, in step 6.:

... MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?

"element" refers to the anchor in <a href="javascript:alert(0)" >click me</a>. The meaning of "navigation" in the context of the HTML standard isn't really relevant. The point is there is no inline script when code dynamically assigns location.href. In integration with HTML section:

[should block inline check] is called during handling of inline event handlers (like onclick)

Where another type of inline event handler is an anchor's href="javascript:...". Code that assigns location.href is not an event handler.

Also elsewhere in the spec:

An inline check, which takes an Element, a type string, a policy, and a source string as arguments

Code that dynamically assigns location.href doesn't satisfy the definition of an "inline check"

[dinofx]

Do you agree that server-side and client-side attacks are two different classes of vulnerabilities?

If so, it would follow that unsafe-inline and unsafe-eval were intended to allow (or not) each of those.

[annevk]

I don't really understand what you are trying to say. The HTML navigate algorithm calls out to CSP to handle javascript: URLs and that's how they are handled. And that's what CSP is talking about when it talks about navigation.

[arturjanc]

Just wanted to point out that there are many other ways to dynamically execute scripts that aren't covered by CSP's 'unsafe-eval' keyword; for example, you can call document.createElement('script') and then assign a string to its text property or a data:text/javascript,... URI to its src and the contents of the string will be evaluated as a script upon attaching the element to the DOM. The Trusted Types spec has more examples.

The CSP spec is fairly clear that having 'unsafe-inline' undoes pretty much any benefit of setting a CSP (see https://w3c.github.io/webappsec-csp/#csp-directives); so does popular developer documentation (e.g. MDN's CSP page). A policy with 'unsafe-inline' but without 'unsafe-eval' will definitely not offer a robust protection against DOM XSS vulnerabilities. If there is any CSP documentation that indicates otherwise, I'd suggest reaching out to the authors to correct it, but I don't think there's any real chance of making a spec/behavior change here.

[dinofx]

I'm saying that "inline" is assumed to be content included in the HTML sent to the browser. The existence of these two directives suggests that someone initially intended for these to protect against server-side attacks vs client-side. Parts of the spec still seem to reflect this, while other parts make it look like the original intention got lost.

[arturjanc]

While your assumption about the relative roles of 'unsafe-inline' and 'unsafe-eval' as mitigating server-side vs. client-side injections would make sense conceptually, this is just not what these CSP keywords have been designed to do. The Reining in the Web with Content Security Policy paper, section 2.1 describes the motivations of the original authors -- 'unsafe-eval' (eval-script in the paper) was specifically intended to cover a subset of programmatic APIs (eval, Function, setTimeout, setInterval) execute code from a string, and not all possible ways to upgrade strings to code at runtime (which include navigations to javascript: URIs, creating <script> elements and setting their text, assigning strings to iframe#srcdoc, and many others).

For actual DOM XSS protection, Trusted Types are the mechanism that aims to guard all DOM code execution sinks and ensure that only objects with a special non-string type can be used in these sinks (and, in fact, they prevent the use of javascript: URIs as you propose, see https://github.com/w3c/trusted-types/blob/main/explainer.md#javascript-urls).

[dinofx]

In Restriction 2: "Strings May Not Become Code" seems unambiguous to me. I think the issue was just that "... as are any equivalent functions" was not a complete inventory of the ways in which strings can become code.

Also in Restriction 1:

javascript: URIs are generally used as a substitute for onclick event handlers, and can be converted to JS functions and initiated as an event handler

Pretty clear the authors were specifically talking about javascript: urls on an anchor, and not location.href = , since the recommended conversion wouldn't apply to the latter.

If there's nothing that can be done at this point, fine. But from a historical perspective, it's clear that there were some gaps in the paper (and probably early versions of the spec), and that those gaps were filled over time in a way that lost the original intent.