Issue metadata
Sign in to add a comment
|
Security: Circumvent CSP Header restrictions via about:blank
Reported by
gro...@gmail.com,
Nov 28 2016
|
||||||||||||||||||||||
Issue description
This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.
Please READ THIS FAQ before filing a bug: https://www.chromium.org/Home
/chromium-security/security-faq
Please see the following link for instructions on filing security bugs:
http://www.chromium.org/Home/chromium-security/reporting-security-bugs
NOTE: Security bugs are normally made public once a fix has been widely
deployed.
VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.
By loading a new document using window.open("","_blank") and document.write-ing into it, (being in about:blank) I can circumvent the CSP restrictions put on the document my js code was running on and reach out to other sites.
One could argue that the code was loaded with unsafe-inline in the CSP header, but that should still block any cross-site communication (e.g. 1x1px tracking image etc).
The about:blank page has the same origin as its loading document, but CSP restrictions have been removed.
I have seen there have been many issues around about:blank, but I have not found any reports just like this.
My tests show that Firefox does not show this behavior, but rather makes the new document inherit CSP from its loading document.
Here is a POC: https://grodum.org/csptest/hey.html
VERSION
Chrome Version: Version 54.0.2840.71 (64-bit) + [stable, beta, or dev]
Operating System: macosx 10.11.6 (15G1108)
REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.
Demo: https://grodum.org/csptest/hey.html
FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: [tab, browser, etc.]
Crash State: [see link above: stack trace, registers, exception record]
Client ID (if relevant): [see link above]
,
Nov 28 2016
Mozilla is expicit about it here: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy Content from about:blank and javascript: URLs inherits the origin from the document that loaded the URL, since the URL itself does not give any information about the origin.
,
Nov 28 2016
+mkwst - do you have thoughts on this? Tentatively assigning medium severity.
,
Nov 29 2016
,
Nov 29 2016
It surprises me that Chrome's not inheriting the policy; the spec is pretty explicit about it: https://w3c.github.io/webappsec-csp/#initialize-document-csp. Sounds like a bug in our implementation.
,
Nov 29 2016
https://codereview.chromium.org/2530343006 up for review.
,
Nov 29 2016
,
Nov 29 2016
,
Nov 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e598765e4822eac833a547abca92ce87a1287dc0 commit e598765e4822eac833a547abca92ce87a1287dc0 Author: mkwst <mkwst@chromium.org> Date: Wed Nov 30 12:36:42 2016 CSP: "local schemes" should inherit policy when window.opened. https://w3c.github.io/webappsec-csp/#initialize-document-csp mandates that resources with "local schemes" ('data:', 'blob:', 'filesystem:', 'about:') inherit the policy of their opening context when opened via things like 'window.open'. We're not doing that, but we ought to. BUG= 669086 R=jochen@chromium.org Review-Url: https://codereview.chromium.org/2530343006 Cr-Commit-Position: refs/heads/master@{#435233} [add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/cross-origin-window-open.html [add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/cross-origin-with-own-policy-window-open.html [add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/same-origin-window-open.html [add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/same-origin-with-own-policy-window-open.html [modify] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/Source/core/dom/Document.cpp
,
Dec 13 2016
mkwst: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 19 2016
Any more changes expected here, or can we close as Fixed?
,
Dec 27 2016
mkwst: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 17 2017
Marking as fixed, please re-open if that's not correct.
,
Jan 18 2017
,
Jan 23 2017
,
Jan 25 2017
,
Jan 27 2017
,
Jan 27 2017
Nice find! The panel decided to award $1,000 for this report. A member of our finance team will be in touch shortly. *** Boilerplate reminders! *** Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing. *********************************
,
Jan 27 2017
,
Jan 30 2017
Awesome, thanks! Btw, I must say I am very impressed with your communication and transparency with me from the moment I reported to you testing and triaging, fixing and code-reviewing. Having reported security issues to many other companies before (even other parts of G), you guys are certainly leaders the field and the way you handle security issues leaves me with confidence in Chrome. Nicolai Grødum
,
Feb 3 2017
,
Feb 3 2017
Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 3 2017
I think this patch landed in M57 to begin with? https://storage.googleapis.com/chromium-find-releases-static/e59.html#e598765e4822eac833a547abca92ce87a1287dc0
,
Feb 3 2017
Please merge your change to M57 branch 2987 before 5:00 PM Pt, Monday (02/06/) so we can pick it up for next week Beta release. Thank you.
,
Feb 9 2017
Please merge your change to M57 branch 2987 before 5:00 PM PT, Friday 02/10 (sooner the better please) so we can take it in for next week beta release. Thank you.
,
Feb 9 2017
I still don't think this needs to be merged. It's already in 57. Dropping the merge flags, CCing govind@ to confirm that I'm holding omahaproxy correctly. :)
,
Feb 9 2017
M57 was branched at Chromium revision 444943 and cl listed at #23 https://chromium.googlesource.com/chromium/src/+/e598765e4822eac833a547abca92ce87a1287dc0 {#435233} so no merged is needed. Thank you mkwst@.
,
Feb 23 2017
,
Mar 6 2017
,
Mar 6 2017
,
Mar 9 2017
,
Apr 26 2017
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
,
Apr 25 2018
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Nov 28 2016