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 1 user
Status: Fixed
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
Content-Security-Policy-Report-Only header isn't enforced when issued alongside the Content-Security-Policy header
Reported by scott.he...@gmail.com, Jun 23 2015 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36

Steps to reproduce the problem:
1. Create and issue a valid CSP and CSPRO header.
2. Load a page with an asset that violates the CSP and CSPRO header.
3. The console only indicates the violation for the CSP and not the CSPRO header.
4. The violation report is only sent for the CSP header and not the CSPRO header.

What is the expected behavior?
The browser should act upon both the CSP and CSPRO header if they are present. The browser should also deliver violation reports for the CSP and CSPRO header if both policies have a report-uri directive specified.

What went wrong?
I issued the following 2 policies on https://scotthelme.co.uk

content-security-policy: default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri https://report-uri.io/report/ScottHelme

content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri https://test.report-uri.io/report/ScottHelme

When visiting https://scotthelme.co.uk/csp-test/, which contains a CSP violation by loading an offending image asset, the console only reports a violation of the CSP header and not the CSPRO header. Further to this, a violation is only sent to the URI specified in the CSP header and not the CSPRO header. 

Tested on Firefox 38.0.5 which works as expected. Violations are displayed and sent for both the CSP and CSPRO header.

Did this work before? N/A 

Chrome version: 43.0.2357.124  Channel: n/a
OS Version: 8.1 Pro x64
Flash Version:
 
chrome.png
92.9 KB View Download
firefox.png
68.5 KB View Download
Comment 1 by jww@chromium.org, Jun 24 2015
Cc: est...@chromium.org jww@chromium.org
Owner: mkwst@chromium.org
Status: Assigned
This does sound like a bug, as per https://w3c.github.io/webappsec/specs/CSP2/#enforcing-multiple-policies, all policies should be enforced/applied. Strictly speaking, this isn't a bug, but until we confirm that this is only occurring with report-only headers, I'm leaving this marked as a security bug.
There are further details associated with handling report only headers here: https://w3c.github.io/webappsec/specs/CSP2/#content-security-policy-report-only-header-field
Comment 3 by mkwst@chromium.org, Jun 25 2015
Certainly sounds like a bug. Both headers should be processed and enforced/monitored.
Comment 4 by mkwst@chromium.org, Jun 25 2015
Labels: -Restrict-View-SecurityTeam -Type-Bug-Security Cr-Blink-SecurityFeature Type-Bug
Ha. Ok. This has never worked correctly. As soon as any policy blocks the request, we skip the rest: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp&l=385 If we'd processed report-only headers first, both would be reported (but we'd still break reporting if there are multiple enforce-mode headers). Hooray for ~4-year old bugs. :/

I don't believe this is a security issue, but it's annoying regardless. Dropping the restrict-view flag, and categorizing correctly.
This issue now appears to be resolved and reports are being sent for the CSPRO header in Version 43.0.2357.134 m. Has there been some change not indicated on this bug?
Update to this bug. Behaviour has changed. 

On this page: https://scotthelme.co.uk/csp-test/
I issue the following policies:

Content-Security-Policy: img-src 'self' data: *snip domains for sanity*; report-uri https://scotthelme.report-uri.io/r/default/csp/enforce

Content-Security-Policy-Report-Only: img-src 'self' data: *snip domains for sanity*; report-uri https://scotthelme.report-uri.io/r/default/csp/reportOnly

The page intentionally loads the following offending asset using the ftp scheme which is not permitted:
<img src="ftp://example.com/profile.png">

I get a CSP report from the enforced policy but *not* from the report-only policy. The policies do differ and Firefox does send a report for each policy for the particular asset. 
After further thought I'm going to raise a new issue as this doesn't exactly match the original issue title. 
 Issue 601212  has been merged into this issue.
Cc: -est...@chromium.org mkwst@chromium.org
Labels: -OS-Windows OS-All
Owner: est...@chromium.org
Mike, I assume you won't be too upset if I take this from you.

I think this is a simple fix as alluded to in comment 4: we just need to loop through all the policies instead of exiting early... I might be missing some subtlety though.
If that's the case, and the report-only header was defined first, does that mean if the report-only policy "blocked" it you'd potentially not check the enforced policy and actually block it?
Re #10: hmmm.... no, I don't think so. We only exit early if the load was actually blocked.

This is the method whose return value we check to decide whether to exit early: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/csp/CSPDirectiveList.cpp&sq=package:chromium&l=241&rcl=1460042158

It returns true if it's a report-only policy, and only returns false if the load violated the policy and the policy is actually being enforced.
Here's a patch, needs moar tests though: https://codereview.chromium.org/1869063003/
Project Member Comment 13 by bugdroid1@chromium.org, May 9 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9

commit c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9
Author: estark <estark@chromium.org>
Date: Mon May 09 19:38:11 2016

Check all CSPs rather than exiting early if a resource is blocked

Previously, if a single policy blocked a resource load, we would exit
early and not check the load against any other policies that might be in
effect. Checking other policies, however, might have side effects (like
sending reports) that should execute even if the load has already been
blocked.

BUG= 503730 

Review-Url: https://codereview.chromium.org/1869063003
Cr-Commit-Position: refs/heads/master@{#392398}

[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-enforce-policies-expected.txt
[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-enforce-policies.php
[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-report-policies-expected.txt
[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-report-policies.php
[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-uri-multiple-expected.txt
[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-uri-multiple-reversed-expected.txt
[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-uri-multiple-reversed.php
[add] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-uri-multiple.php
[modify] https://crrev.com/c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp

Labels: M-52
Status: Fixed
Sign in to add a comment