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

Issue 603221 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

The upgrade-insecure-requests directive does not trigger reports.

Reported by scott.he...@gmail.com, Apr 13 2016

Issue description

Chrome Version       : 49.0.2623.112
OS Version: 10.0
URLs (if applicable) : https://scotthelme.co.uk/cspro-upgrade-insecure-requests-test/
Other browsers tested: none

What steps will reproduce the problem?
1. Visit the URL above. It includes an example of a resource that would be upgraded with upgrade-insecure-requests.
2. Note that no report is sent for the breach of CSPRO header.

What is the expected result?
The asset on the page would be upgraded if the policy were enforced. I would expect a report to be sent if the policy is in report-only mode so the asset can be detected during testing.

What happens instead of that?
No report is sent so the host would be unaware that a resource on this page would be upgraded.

UserAgentString: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36



 
I've added an enforced version of the policy here: https://scotthelme.co.uk/csp-upgrade-insecure-requests-test/

Is it possible HSTS is interfering here? 
In the report-only version, I get a 307 from Chrome triggered by HSTS. I assume this is because the upgrade-insecure-requests directive is not being enforced and HSTS is kicking in. 

In the enforced version I do not get a request to the insecure resource and it the first request is for the upgraded secure resource, which suggests this is not actioned by HSTS but by CSP. 

No reports are sent in either scenario. 
Components: Internals>Network>HTTP
Labels: Te-NeedsFurtherTriage

Comment 4 by mmenke@chromium.org, Apr 21 2016

Cc: mkwst@chromium.org est...@chromium.org
Components: -Internals>Network>HTTP Blink>Loader
[+jww, +estark]:  Either of you know who owns the CSP stuff?

Comment 5 by mkwst@chromium.org, Apr 21 2016

Cc: jww@chromium.org
Moi. Also Emily and Joel. Joel was telling me just this morning that he totally wants to work on more CSP stuff, actually!

Would you be interested in looking into this, Joel?

Comment 6 by est...@chromium.org, Apr 21 2016

Components: Blink>SecurityFeature

Comment 7 by mkwst@chromium.org, Apr 21 2016

Actually, looking at the demo, this page won't generate a violation report; there's no `img-src` directive that's violated.

`upgrade-insecure-requests` doesn't generate a violation in and of itself. There's a request for it (and `block-all-mixed-content`) to do so, but that behavior isn't specced yet. Want to take a stab at https://github.com/w3c/webappsec-csp/issues/26?

Comment 8 by kinuko@chromium.org, Apr 28 2016

Owner: jww@chromium.org
Status: Assigned (was: Unconfirmed)
Should this bug be closed but need another issue for 'block-all-mixed-content'?

Taking the Mike's word from #5, tentatively assigning this to jww@

Comment 9 by mkwst@chromium.org, May 23 2016

I think this is WAI. Filed https://bugs.chromium.org/p/chromium/issues/detail?id=613956 for the 'block-all-mixed-content' request.

Comment 10 by mkwst@chromium.org, May 23 2016

Status: WontFix (was: Assigned)

Sign in to add a comment