Closed Bug 1015631 Opened 6 years ago Closed 6 years ago

Mixed content blocking doesn't check intermediate redirects

Categories

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

defect
Not set
minor

Tracking

()

RESOLVED DUPLICATE of bug 418354

People

(Reporter: lcamtuf, Unassigned)

References

Details

(Keywords: sec-low)

Hey,

Mixed content checking doesn't appear to catch a situation where the initial URL is HTTPS, results in a redirect to HTTP, and that again redirects to HTTPS. One example of this would be something like:

<script src="https://www.example.com/whatever_v1.js">

...that mistakenly redirects to:

http://www.example.com/whatever_v2.js

...and that then gets upgraded back to HTTPS:

https://www.example.com/whatever_v2.js

On open wifi, active attackers could intercept that middle redirect and make it point to https://www.evil.com/evil.js, so this is obviously undesirable. Chrome detects and blocks this redirect.

Test case: go to a HTTPS site like https://www.paypal.com and try this in the console:

s=document.createElement('script');s.src='https://1-ps.googleusercontent.com/h/lcamtuf.coredump.cx/mixme1.cgi';document.body.appendChild(s)

Note that the redirect chain goes through a HTTP step.
I don't think this needs to be a hidden bug.
Component: Security → DOM: Security
Product: Firefox → Core
See Also: → 418354
tanvi - do you agree on opening this bug?
Flags: needinfo?(tanvi)
You don't even need to redirect back to https, we just don't handle redirects in the initial implementation.
Group: core-security
Status: NEW → RESOLVED
Closed: 6 years ago
Keywords: sec-low
Resolution: --- → DUPLICATE
Duplicate of bug: 418354
Yes, we can open this up.  This is a known issue which will be fixed as part of bug 1006868.
Flags: needinfo?(tanvi)
You need to log in before you can comment on or make changes to this bug.