1433687 - "Content-Security-Policy: upgrade-insecure-requests" header on initial page causes redirects error on link open that redirects to HTTP

Status: RESOLVED DUPLICATE of bug 1422284

(Core :: DOM: Security, defect)

Description

[Vsevolod]

Attachment: Screen Shot 2018-01-27 at 9.26.54 PM.png

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

Steps to reproduce:

1. I opened secure page_a on my site that has "Content-Security-Policy: upgrade-insecure-requests" header
2. Clicked https link to page_b -- the request was redirected with status 302 to http version of page_b (since https has not been fully implemented yet for that page)


Actual results:

I got "The page isn’t redirecting properly" error in Firefox. In dev toolbar I see that the request is upgraded to secure again and again so redirect happens many times and eventually browser shows the mentioned error.
So what happens here:
1. Link "https://my-site/page_b" is clicked on page with url "https://my-site/page_a" and header "Content-Security-Policy: upgrade-insecure-requests" set
2. Web-server returns 302 redirect to page "http://my-site/page_b"
3. URL "http://my-site/page_b" is upgraded by browser to secure version "https://my-site/page_b"
4. Request to "https://my-site/page_b" is made
5. Steps 2-4 are repeated many times until redirects limit is reached; error is shown.



Expected results:

Insecure version of page_b should be opened.

Some sites cannot switch to https at once entirely and do gradual migration, switching pages from http to https one by one. In our case all links on a page have the same scheme as page itself (so all links on https page have https scheme, even if they redirect to http page when clicked). So https->http redirect for them should not be upgraded since it breaks the site and renders meaningless "Content-Security-Policy: upgrade-insecure-requests" header which is intended to mitigate process of migration from http to https.

Comment 1

[Vsevolod]

Here is a demo page that I've created to demonstrate the bug https://precious.alwaysdata.net/cgi-bin/page_a.py

I've also checked this case in browsers Chrome and Safari and it works without issues there.

Comment 2

[Vsevolod]

The bug is also reproducible in beta version Firefox 59.0b4 and nightly build Firefox 60.0a1

Comment 3

[Vsevolod]

Looks like the bug appeared first in Firefox version 57.

Comment 4

[Gingerbread Man]

https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=b91870ea1243520ffa057fad90a655f24a398d5d&full=1

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

Hey Vsevolod, thanks for reporting. That sounds very much similar to the problem reported within Bug 1422284. In fact, the STRs within comment 4 [1] are identical as far as I can tell. If not please let me know. Otherwise please follow Bug 1422284 for progress. I will have someone look into the problem ASAP.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1422284#c4

Comment 6

[Vsevolod]

Hello Christoph. Yes, looks like the summary in comment 4 in Bug 1422284 is applicable to the current issue.