CSP: Chromium sending base-uri CSP violation reports for 'self' resources |
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.37 Safari/537.36 Steps to reproduce the problem: I am receiving CSP violation reports for base-uri with blocked-uri in 'self', even if base-uri 'self' is set. CSP policy: object-src 'none';script-src 'nonce-REDACTED' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;base-uri 'self';report-uri /report The violation report has a blocked-uri which is same-origin as document-uri. Both violated-directive and effective-directive are "base-uri". What is the expected behavior? The resource in 'self' should be allowed and should not trigger a violation report. What went wrong? Affected UA strings (Chrome 55, 56, 57): Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.21 Safari/537.36 Did this work before? N/A Chrome version: 56.0.2924.87 Channel: beta OS Version: Flash Version:
,
Feb 15 2017
I was able to reproduce non-deterministically also on pages not in sandboxed frames, such as https://myaccount.google.com/not-supported. I have sent you an email with more details.
,
Feb 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9d3329c4a3d3dd0ab85869b7de4d62a8e2797520 commit 9d3329c4a3d3dd0ab85869b7de4d62a8e2797520 Author: mkwst <mkwst@chromium.org> Date: Mon Feb 20 15:04:02 2017 CSP: 'self' should work inside sandboxes. We ought to be looking at the URL of a sandboxed resource when resolving the CSP source expression 'self'. Currently, we're looking at the origin of the resource, which is generally correct, but fails if the resource has been pushed into an opaque origin. This patch uses the fallback base URL of a document rather than its origin to do the comparison. BUG=692475 R=jochen@chromium.org CC=andypaicu@chromium.org Review-Url: https://codereview.chromium.org/2699663002 Cr-Commit-Position: refs/heads/master@{#451626} [add] https://crrev.com/9d3329c4a3d3dd0ab85869b7de4d62a8e2797520/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/base-uri-self.html [modify] https://crrev.com/9d3329c4a3d3dd0ab85869b7de4d62a8e2797520/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp [modify] https://crrev.com/9d3329c4a3d3dd0ab85869b7de4d62a8e2797520/third_party/WebKit/Source/core/frame/csp/SourceListDirectiveTest.cpp
,
Feb 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4 commit 3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4 Author: mkwst <mkwst@chromium.org> Date: Sat Feb 25 14:45:21 2017 Revert of CSP: 'self' should work inside sandboxes. (patchset #2 id:20001 of https://codereview.chromium.org/2699663002/ ) Reason for revert: I suspect that this breaks Synology's UI, which submits a form through an `about:blank` frame. Perhaps we're not persisting the fallback base URL correctly? BUG= 695058 Original issue's description: > CSP: 'self' should work inside sandboxes. > > We ought to be looking at the URL of a sandboxed resource when resolving > the CSP source expression 'self'. Currently, we're looking at the origin > of the resource, which is generally correct, but fails if the resource > has been pushed into an opaque origin. > > This patch uses the fallback base URL of a document rather than its > origin to do the comparison. > > BUG=692475 > R=jochen@chromium.org > CC=andypaicu@chromium.org > > Review-Url: https://codereview.chromium.org/2699663002 > Cr-Commit-Position: refs/heads/master@{#451626} > Committed: https://chromium.googlesource.com/chromium/src/+/9d3329c4a3d3dd0ab85869b7de4d62a8e2797520 TBR=jochen@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=692475 Review-Url: https://codereview.chromium.org/2711363004 Cr-Commit-Position: refs/heads/master@{#453091} [delete] https://crrev.com/c5f5f6b86a87487c82e1967fcf523633f43e8f21/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/1.1/base-uri-self.html [modify] https://crrev.com/3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp [modify] https://crrev.com/3a1bb4d2c8bd64fdf57558d2ff39a5f356597af4/third_party/WebKit/Source/core/frame/csp/SourceListDirectiveTest.cpp
,
Mar 15 2017
There's a variant of this bug, that apparently affects the CSP of sandboxed extension resources: 'self', in those policies, appears to match the post-sandboxing unique origin, rather than the chrome-extension URL. It's a moot issue at tip of tree, where chrome-extension: bypasses the CSP. But it matters if we remove the chrome-extension bypass, which I'm hoping to do inside of extension processes. Mike, knowing that there's existing web content like the Synology UI, what can we do here? Is the spec clear on whether 'self' indicates the pre- or post- sandboxing origin?
,
Jul 27 2017
,
Nov 10 2017
,
Feb 18 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mkwst@chromium.org
, Feb 15 2017Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam M-58 OS-Android OS-Chrome OS-Mac OS-Windows Type-Bug
Owner: mkwst@chromium.org
Status: Assigned (was: Unconfirmed)