CSP Report Only Enforces Blocking
Reported by
aidantwo...@gmail.com,
Oct 24 2016
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Steps to reproduce the problem:
1. Issue the following header:
Content-Security-Policy:script-src 'sha256-mKJDJIdVRrRXhbmGO1dKifUUG6KL/F8a5QDbfPQhijY=';
And echo out the following script (which hashes to the value in the header):
<script>window.onload=function(){document.body.style="background:green;";}</script>
Observe that Chrome (correctly) allows this script to run.
2. While still issuing the previous header, issue an additional header:
Content-Security-Policy-Report-Only:default-src 'self';
Again, echo out the previous script.
Observe that Report-Only mode has affected the enforced policy, the background is no longer green.
Additionally look in console for:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'sha256-mKJDJIdVRrRXhbmGO1dKifUUG6KL/F8a5QDbfPQhijY='". Either the 'unsafe-inline' keyword, a hash ('sha256-mKJDJIdVRrRXhbmGO1dKifUUG6KL/F8a5QDbfPQhijY='), or a nonce ('nonce-...') is required to enable inline execution.
The console helpfully provides a hash as a suggested value, right after listing the exact same hash as part of the violated policy.
What is the expected behavior?
Both enforced behaviours are identical.
(Though, report only should issue a browser console warning about the lack of a hash in script-src).
What went wrong?
CSPRO is affecting the behaviour of CSP (enforced) – even though it shouldn't.
Did this work before? N/A
Chrome version: 53.0.2785.143 Channel: n/a
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 23.0 r0
Let me know if you can't easily reproduce the problem, I'll stick a test page up.
,
Oct 24 2016
https://whytls.com/test/csp/cspro.php Chrome 55: Repro Chrome 56.2899: Repro Firefox 51: NOT repro
,
Oct 24 2016
Yup that's fine (unfortunately I couldn't categorise as 'SecurityFeature' in the initial dialogue – so 'Security' was the closest I could get!) Test page is accurate :)
,
Nov 2 2016
I was just reading part of the CSP spec that details behaviour very similar to this issue. See: https://www.w3.org/TR/CSP/#multiple-policies If Chrome were to receive an additional Enforced header, then the blocking behaviour here would be inline with spec. Though, since it isn't an Enforced header – I think Chrome may be incorrectly treating the received Report-Only as Enforced when applying the spec above. Just thought I'd post the link here as it may help narrow down the issue :)
,
Feb 23 2017
Looks like we're doing the wrong thing with hashes, similar to the issues we had with nonces in the past. Wonderful.
,
Mar 6 2017
,
Nov 10 2017
,
Dec 21 2017
On revisiting the test page in 63.0.3239.84, this appears to have been fixed.
,
Jan 22 2018
Apparently we fixed it! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by elawrence@chromium.org
, Oct 24 2016Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug