In the attack scenario, an attacker with a cross-site scripting vulnerability in CSP-protected page P1 on Example.com can use that vulnerability to run script in unprotected P2 on Example.com.

It's unclear how this would be interesting from a security point-of-view. At the point that the attacker has the ability to run JavaScript inside P1, he's already achieved script execution within the target domain.

Presumably, this scenario would be addressed by the Origin Policy proposal: https://wicg.github.io/origin-policy/

I'm interested to know how attacker can run javascript using only P1 (Which has CSP).

Right. So the concern is that CSP does not necessarily prevent a page with an XSS vulnerability from being used as a trampoline such that the attacker-injected payload executes in a same-origin page lacking the protections of CSP.

Yes, that's what I wanted to discuss.

Major websites known to be very good at CSP doesn't set CSP header to their robots.txt.

https://github.com/robots.txt (Github has CSP bypass bounty too)
https://twitter.com/robots.txt

If they have such XSS that tries to write or innerHTML attacker injection to another window or frame with which attacker has control to, robots.txt could be used to bypass CSP.

1. I don't really understand the demo: I don't see CSP headers being set on either https://test.shhnjk.com/inner.html or https://test.shhnjk.com/robots.txt. Where does a policy come into play?

2. I generally agree with Eric: once you have script execution on any page of `https://example.com/`, you're done: `example.com` is yours. I don't think being able to manipulate other pages on the origin grants you any additional privileges that script execution doesn't already grant you. Can you help me understand what you think is going wrong here?

1. view-source:https://test.shhnjk.com/inner.html#robots.txt has CSP as a META:

 <meta http-equiv="Content-Security-Policy" content="default-src 'self';">

2. I think the idea here is that it would be nice/interesting if CSP had a means of preventing a CSP-protected document from "jurisdiction shopping". Today, a document protected via CSP is still same-origin to all other documents on the origin, including those with a weaker CSP. This means that a CSP-protected document which contains an XSS "trampoline" can be used to attack a page that itself lacks an XSS vulnerability but also lacks a CSP. In this way, the XSS payload can be smuggled into a context that will allow it to execute.

Put another way: Origin Policy is needed, and CSP cannot prevent Web Developers from building trampolines.

+aaj for potential interest

andypaicu@chromium.org, I'll leave to you to decide if you want to look into doing something about item (2) in #6.

But it seems we don't have a bug in Chrome's CSP enforcement, given how CSP is currently specified. Is that right? If experts agree, I'll open this bug to the public and call it a security feature request?

I understand the point of the report but agree with all the replies, i.e. this is not a vulnerability and we can make this bug public.

IIUC the issue s.h.h.n.j.k is getting at is that a page with CSP might have legitimate (non-injected) code which can take untrusted data (e.g. location.hash, something from the DOM, etc.) and insecurely write it to a same-origin document which doesn't have CSP, and where this untrusted data will lead to script execution.

In this case there is no malicious script execution in the original page (the one with CSP), because it just writes data to another same-origin document; similarly, there is no vulnerability in the second document (the one without CSP) because it just gets written to by a trusted same-origin page. One might think that having CSP on the initial document would protect against script execution, but in practice it doesn't.

I see it as an instance of the "script gadgets" class of issues (https://www.blackhat.com/docs/us-17/thursday/us-17-Lekies-Dont-Trust-The-DOM-Bypassing-XSS-Mitigations-Via-Script-Gadgets.pdf) where legitimate code can process attacker-controlled data in a way that leads to subverting security restrictions (in some cases, allowing full JS execution and bypassing CSP). However, as with some other gadgets, this case seems fairly unlikely to arise in practice because it's not very common to have JS code that allows writing user-influenced markup to arbitrary same-origin windows/frames, and many users of CSP enable their policy domain-wide. So even if such a gadget exists, it would likely write to a frame with a developer-controlled URL, which is more likely to have CSP than an attacker-chosen document such as robots.txt.

Overall it's a reasonable finding, but I don't think it's either a Chrome or CSP spec issue.

Cheers,
-Artur

Thanks, Artur.

A quick search did not turn up an existing feature request for Origin Policy; if there is one, feel free to duplicate this bug into that one.

Duping into 751996, where we're working on Origin Manifests.