Stop treating "http://localhost/" (by name) as mixed content
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox84 | --- | fixed |
People
(Reporter: hirschbeckdaniel, Unassigned, NeedInfo)
References
(Blocks 4 open bugs)
Details
(Keywords: dev-doc-complete, Whiteboard: [domsecurity-backlog1])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce: A GET was called from a https domain to localhost on http. After that a POST call was sent on same way. Actual results: The POST call was aborted. Expected results: Mixed content calls should be enabled to localhost. The W3C is recommend to allow this behavior. https://w3c.github.io/webappsec-mixed-content/#terms
Hi hirschbeckdaniel, Thanks for reporting this issue. Can you provide a specific example/test case for the https GET/POST to see if this issue can be reproduced? Thanks.
Comment 2•6 years ago
|
||
As I understand, you expect requests made to http://localhost being treated as secure, right? That is not a valid assumption, IMO. I can't find any reference to treat localhost insecure requests as secure regarding mixed content blocking in the spec reference from comment 0. I *think* the mixed content blocker issues belong to the security component.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 5•6 years ago
|
||
(In reply to vincent.privat from comment #4) > (In reply to Honza Bambas (:mayhemer) from comment #2) > > As I understand, you expect requests made to http://localhost being treated > > as secure, right? That is not a valid assumption, IMO. > > Yes it is, since Firefox 55 which fixes > https://bugzilla.mozilla.org/show_bug.cgi?id=903966 > > I see users are reporting similar problems there with Firefox 60+ Good point. I was not aware of that bug to be honest as it went totally around the necko code. I'm moving this bug to the same component and adding some folks.
Comment hidden (obsolete) |
Comment 7•6 years ago
|
||
hirschbeckdaniel - Could you provide the specific error that the browser console displays when the load is blocked. It might actually be a CORS error instead of a mixed content blocker error.
Comment 8•6 years ago
|
||
Here the error code from the browser when trying to do an ajax request from a https:// website to http://localhost. "Blocked loading mixed active content "http://localhost:49101/" For my understanding of the w3c specs, this call should be allowed.
Comment 9•6 years ago
|
||
(In reply to Simone Granata from comment #8) > Here the error code from the browser when trying to do an ajax request from > a https:// website to http://localhost. > "Blocked loading mixed active content "http://localhost:49101/" > > For my understanding of the w3c specs, this call should be allowed. See: https://bugzilla.mozilla.org/show_bug.cgi?id=903966
Hey Birunthan, any chance you could take a look at this bug? Within Bug 903966 we started to allow mixed content requests to localhost. I just browsed the code and in my opinion IsPotentiallyTrustworthyLoopbackURL() does the right thing on the right spot within nsMixedContentBlocker and therefore should also greenlight that ajax request from comment 8. Not sure where the problem is, could you try to debug and potentially add a test so we don't regress that again? Thanks! [1] https://searchfox.org/mozilla-central/source/dom/security/nsMixedContentBlocker.cpp#745
Updated•6 years ago
|
I am going to assign this one to myself and take a look. Probably there is so mis-alignment with the secure context spec since the MixedContentBlocker code looks sane to me. Anyway, I'll have a look.
Updated•6 years ago
|
Comment 12•6 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #2) > I can't find any reference to treat localhost insecure requests as secure > regarding mixed content blocking in the spec reference from comment 0. It's a "MAY" in the secure contexts spec (referenced from the mixed content spec https://w3c.github.io/webappsec-secure-contexts/#localhost
Comment 13•6 years ago
|
||
this is likely to be optional. we must disable it for our localhost-based tests and also allow developers (platform and firefox) to disable it when local testing work regarding content blocking is under way. thanks.
Updated•6 years ago
|
Comment 14•6 years ago
|
||
The isSecureContext checks already treat "localhost" the right way, so this bug is essentially about aligning the mixed-content blocker with that, which is bug 1295777. Possibly want to dupe this to that, but for now I'll make it "depends on" for clarity.
Comment 15•6 years ago
|
||
Possible dupe of: Bug 1402530
So I think that isSecureContext
result traverses all loadInfo arguments using IsOriginPotentiallyTrustworthy
either way it should be checked and unified.
It seems I just don't get to fixing this at the moment - I'll try to find someone in the team to take a look at this one.
Updated•5 years ago
|
Comment 17•5 years ago
|
||
Any updates on this? This is a pretty big issue for me. Trying to run through this tutorial, I installed about 5 CORS plugins before I realized this was a specific issue since Firefox 58.
Comment 18•5 years ago
|
||
Any progress on this? It seems to work fine in Chrome and it would be great to have parity...
Cheers. G.
Updated•5 years ago
|
Comment 20•5 years ago
|
||
This is pretty important to fix for many companies I guess. We are affected here by using atlassian companion app for attachment editing in confluence. It doesn't work right now with ESR version without setting network.websocket.allowInsecureFromHTTPS to true which would mean more security risks.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 21•4 years ago
|
||
Bug 1220810 landed ; localhost/ and *.localhost/ are treated as "Potentially Trustworthy" as described in https://w3c.github.io/webappsec-secure-contexts/#localhost
Updated•4 years ago
|
Comment 22•4 years ago
|
||
FYI Doc for this captured in Mixed content > Loading locally delivered mixed-resources
For more info see https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c91 and https://github.com/mdn/sprints/issues/3906#issuecomment-728667532
Updated•4 years ago
|
Description
•