New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue 751996
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Feature



Sign in to add a comment

CSP bypass by setting innerHTML on a same-origin page lacking CSP

Reported by s.h.h.n....@gmail.com, Sep 12 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36

Steps to reproduce the problem:
1.  Go to https://test.shhnjk.com/inner.html#robots.txt?<img/onerror="alert(document.domain)"/src=x>
2. Click go

What is the expected behavior?
DOM baed XSS would be blocked with CSP.

What went wrong?
Opening Non-CSP page and innerHTML-ing from CSP-ed page with XSS is possible.

Did this work before? N/A 

Chrome version: 61.0.3163.79  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 
Cc: mkwst@chromium.org
Components: Blink>SecurityFeature>ContentSecurityPolicy
Labels: OS-Android OS-Chrome OS-Linux OS-Windows
Summary: CSP bypass by setting innerHTML on a same-origin page lacking CSP (was: CSP bypass with innerHTML-ing same-origin page)
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).
Cc: andypaicu@chromium.org
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.

Comment 5 by mkwst@chromium.org, Sep 13 2017

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.

Comment 7 by palmer@chromium.org, Sep 19 2017

Cc: -andypaicu@chromium.org a...@google.com
Labels: OS-Fuchsia
Owner: andypaicu@chromium.org
Status: Assigned (was: Unconfirmed)
+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?

Comment 8 by a...@google.com, Sep 20 2017

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

Comment 9 by palmer@chromium.org, Sep 21 2017

Cc: elawrence@chromium.org
Components: Security
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Feature
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.

Comment 10 by mkwst@chromium.org, Sep 21 2017

Mergedinto: 751996
Status: Duplicate (was: Assigned)
Duping into 751996, where we're working on Origin Manifests.

Sign in to add a comment