Issue metadata
Sign in to add a comment
|
Security: chrome CORS bypass via iframe and window.open
Reported by
steventh...@gmail.com,
May 27 2016
|
||||||||||||||||||||||
Issue descriptionGoogle Chrome CORS/SOP bypass via window.open & iframe VULNERABILITY DETAILS ===================== This poc bypasses CORS (Access-Control-Allow-Origin header) by (ab)using a reflective XSS on a target. The XSS payload does a PUT request, and since it executes in the context of the localhost slips past the CORS check. It maybe possible for an attacker to access the pages response from iframe as well, since its actually there, just that the API I have played with blocks it so far. VERSION ======= Chrome Release - 50.0.2661.102 (Windows x86) OS: Windows 7 Ultimate x86 full patched REPRODUCTION CASE ================= 1. Start the poc.py file on the same host as the chrome installation. 2. Start a webserver on your "attackers" machine where the html and js files are. 3. from the client, browse to attackers webserver where the html files are hosted. notes: You may need to update the hardcoded IP addresses to replay the attack. The attached screenshot should help in understanding the flow.
,
May 31 2016
,
Jun 2 2016
,
Jun 2 2016
Hi there, and thanks for the report. I think I may be confused about the attack and proof-of-concept. It seems to me that there is simply an XSS in the application, which is then exploited to execute a PUT via XHR. In particular, when your POC executes the window.open, the new window that opens is in a new origin, namely the origin of the server you're trying to attack, so it's not surprising at all that there wouldn't be CORS headers sent (since the XSS is executing in the same-origin as the server). The same reasoning applies to the iframe example. So while it's bad that the XSS exists, this appears to me to be an XSS issue with the application, and not a Chrome bug. Can you confirm or explain my mistake? Thanks!
,
Jun 2 2016
The iframe and the window.open is not executing the new origin. Those are the first pieces of JS to execute and is executed before the XSS fires. The XSS is used to then circumvent CORS further.
,
Jun 5 2016
,
Jun 6 2016
,
Jun 6 2016
,
Jun 7 2016
So here's my understanding of what's going on:
-- <html> document at origin1
-- contains <iframe> at origin2
-- contains XSS injected <script> poc.js, loaded from origin1
-- makes XHR request to origin2, which successfully returns
content (without CORS) and the put is executed on the origin
This is working as intended. Although the script is *loaded from* origin1, it *executes* in origin2. Thus, when it makes the XHR to origin2, it has the full authorization and credentials of origin2, so it's not a cross-origin request and is fully allowed without ACAO headers needed.
At a higher level, the web platform explicitly does not require CORS for window.open and iframes. They are intended to be mechanisms that allow the content to be referenced as a separate security context without actually giving access to the content itself.
Based on this, it is WAI, so I'm marking as WontFix. However, if you still feel that I'm wrong, please do update this thread and correct me. It's possible that I've missed somethingh as your PoC scripts didn't work out of the box, and I had to change quite a bit to get them up and running. Thanks!
,
Sep 14 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mea...@chromium.org
, May 31 2016