1447784 - Content-Security-Policy upgrade-insecure-requests should not be applied to 127.0.0.0/8

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P2)

Description

[Ryan Knotts]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Steps to reproduce:

1. Set up a web page to include the Content-Security-Policy header with the upgrade-insecure-requests directive
2. In the supplied web page, make a request to http://127.0.0.1:<someport> via XMLHttpRequest object.
3. Note that the XMHttpRequest is made via https in the console logs.



Actual results:

CORS requests to 127.0.0.0/8 and ::1 made over HTTP are being modified to be made over HTTPS. The local application listening therefor misses the requests, since they are listening for HTTP requests.



Expected results:

Given that per the W3C spec 127.0.0.0/8 and ::1 are considered a trustworthy origin when using HTTP:
https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
The expectation is that HTTP requests to 127.0.0.0/8 and ::1 are NOT modified to HTTPS when the upgrade-insecure-requests directive is applied.

Note that 127.0.0.0/8 is trusted in Mozilla as per https://bugzilla.mozilla.org/show_bug.cgi?id=903966, where it is no longer blocking mixed content pages.

Comment 1

[Ryan Knotts]

Attachment: Repro test code

Hi, attaching a file which replicates the issue. You can see in the Network console that the request to http://127.0.0.1/ is sent by https if the Content-Security-Policy: upgrade-insecure-requests is set, and is sent by http if it is not set (can comment out that line from the file to test that case). Let me know if you have any problems with this.

Comment 2

[Christoph Kerschbaumer [:ckerschb}]

That makes sense to me.

Jonathan, any chance you could fix that?

Comment 3

[bpliskow]

Christoph/Jonathan - Appreciate the consideration given to this bug report. It's been a month since the last update. Any chance this will be picked up in an upcoming development sprint?

Comment 4

[saikiran.dhalli]

Hello... Is there any update on this issue?

Comment 5

[Jonathan Kingston [:jkt] he/him]

Chrome behaves the same here, the specification is actually somewhat vague but I think we have the correct behaviour based on the spec text.

As mentioned "Is Origin Is Potentially Trustworthy" is true when the host is a loopback.
This check is however used only with checking for if to send the "Upgrade-Insecure-Requests" header in (https://w3c.github.io/webappsec-upgrade-insecure-requests/#upgrade-request) 4.1.1.
- This suggests we shouldn't send the header for secure contexts that are preloaded.

However in 4.1.3 the settings object is checked of the responsible document which in this case returns "Upgrade" so the algorithm continues to 4.1.(4-6) which upgrades "http://127.0.0.1:80" to "https://127.0.0.1:443".

The heading of 4.1 "Upgrade request to an a priori authenticated URL, if appropriate" implies that if the connection is already "a priori authenticated" then we shouldn't upgrade. However I don't think a heading would be considered normative.

mkwest:
1. Should the specification change for this edge case?
2. I started doing this work and tried to add a web-platform-test for it and I don't think it would be possible given how the current tests work / the lack of the server isn't on 127.0.0.1 etc.
3. Looks like firefox only cares about 127.0.0.1 here, we should probably fix that.

Comment 6

[Jonathan Kingston [:jkt] he/him]

Attachment: bug-1447784.patch

WIP patch, test doesn't work as mentioned.

Comment 7

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1447784 - stop upgrading potentially trustworthy URLs from being upgraded by UIR.

Review commit: https://reviewboard.mozilla.org/r/243340/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/243340/

Comment 8

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8974952 [details]
Bug 1447784 - stop upgrading potentially trustworthy URLs from being upgraded by UIR.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/243340/diff/1-2/

Comment 11

[saikiran.dhalli]

Appreciate the efforts on this ticket so far. Any updates on when this fix will be released ?

Comment 12

[bpliskow]

Any updates on this bug/fix?

Comment 13

[Jonathan Kingston [:jkt] he/him]

We are still blocked on the issue in this PR: https://github.com/web-platform-tests/wpt/pull/5304 basically we can't land a web platform test due to the limitations there. We should just write our own test in the interim.

Comment 14

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1447784 - Upgrade insecure requests should not be applied to potentially trustworthy loopback

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/513eb6ea5f31
Upgrade insecure requests should not be applied to potentially trustworthy loopback r=baku

Comment 16

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/513eb6ea5f31