Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I have two questions regarding the CSP directive upgrade-insecure-requests which I couldn't answer myself by reading the specification.
report-uri in the policy? Just failed upgrades or also successful upgrades?What happens to ressources which can't be upgraded to https (e.g. invalid certificate)? Will they be blocked?
The request will be made over HTTPS. If the request fails, then it fails. To do otherwise would open the system up to downgrade attacks, making it effectively useless against a MITM attacker.
This behavior is specified in the Fetch Standard from the WHATWG (which is referenced in the upgrade-insecure-requests spec):
- Upgrade request to a potentially secure URL, if appropriate.
Since this step happens before any actual network requests are made, the rest of the process behaves exactly as if the request was originally made as HTTPS from the beginning.
What kind of violations will be reported against the endpoint specified by
report-uriin the policy? Just failed upgrades or also successful upgrades?
No violations will be reported by a CSP directive using upgrade-insecure-requests. According to the spec:
Monitoring the upgrade-insecure-requests directive has no effect: the directive is ignored when sent via a Content-Security-Policy-Report-Only header. Authors can determine whether or not upgraded resources' original URLs were insecure via Content-Security-Policy-Report-Only. For example,
Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint. See §3.4 Reporting Upgrades for additional detail.
So if you want information on which requests are being upgraded using CSP, you must use a hard fail (not upgrade-insecure-requests) with the Report-Only header.
Section 3.4 further explains this in example 9:
Within the context of a protected resource which contains the insecure image
<img src="http://example.com/image.png">, and delivers the following HTTP headers:Content-Security-Policy: upgrade-insecure-requests; default-src https: Content-Security-Policy-Report-Only: default-src https:; report-uri /endpointThe user agent will fire off a request request that:
- Violates the policy being monitored, thereby delivering a violation report to /endpoint.
- Is upgraded from http://example.com/image.png to https://example.com/image.png.
- Does not violate the policy being enforced.
Note that point 3 here is key. Since the request is upgraded in step 2, the request does not "violate the policy being enforced". According to the CSP spec, only violations of the CSP policy are reported:
When one or more of a policy’s directives is violated, a violation report may be generated and sent out to a reporting endpoint associated with the policy.
Content-Security-Policy and therefore won't fire off violation reports. Can you elaborate on the case that Content-Security-Policy has set a report-uri and the upgrade fails? Then there will be a report, right?
Nov 13, 2017 at 21:11
Exactly the same thing that would happen if a non-upgraded HTTPS request failed. The spec talks about rewriting requests. Exactly how this is done is explained in section 4.1 of the spec, but the essence is that http:// is replaced with https://. That means that once the request is rewritten it is indistinguishable from a request that was HTTPS from the beginning.
To be honest I can't find any good section of the spec to quote where this is crystal clear. But example one and three quite directly show that this is the case.
No successful upgrades, no failed upgrades, nothing. From section 3.1 of the spec:
Monitoring the
upgrade-insecure-requestsdirective has no effect: the directive is ignored when sent via aContent-Security-Policy-Report-Onlyheader.
report-uri directive in a Content-Security-Policy (not Content-Security-Policy-Report-Only).
Nov 13, 2017 at 21:06