New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 658720 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug
csp


Show other hotlists

Hotlists containing this issue:
EnamelAndFriendsFixIt


Sign in to add a comment

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.
 
Cc: mkwst@chromium.org
Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Untagging as a security bug, as the problem reported is "Fails in the direction of secure"
Status: Untriaged (was: Unconfirmed)
https://whytls.com/test/csp/cspro.php

Chrome 55:      Repro
Chrome 56.2899: Repro
Firefox 51:     NOT repro
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 :)
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 :)

Comment 5 by mkwst@chromium.org, Feb 23 2017

Labels: csp OS-Android OS-Chrome OS-Linux OS-Windows
Status: Available (was: Untriaged)
Looks like we're doing the wrong thing with hashes, similar to the issues we had with nonces in the past. Wonderful.

Comment 6 by mkwst@chromium.org, Mar 6 2017

Components: Blink>SecurityFeature>ContentSecurityPolicy

Comment 7 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt
On revisiting the test page in 63.0.3239.84, this appears to have been fixed.

Comment 9 by mkwst@chromium.org, Jan 22 2018

Status: Fixed (was: Available)
Apparently we fixed it!

Sign in to add a comment