1488740 - Stop treating "http://localhost/" (by name) as mixed content

Status: RESOLVED FIXED

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

Description

[hirschbeckdaniel]

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

Comment 1

[u554753]

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

[Honza Bambas (:mayhemer)]

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 3

[vincent.privat]

Hello,
We have the same problem with JOSM, Osmose and FF 62.0.2. To reproduce you can test as follows:
- launch JOSM: https://josm.openstreetmap.de/download/josm.jnlp
- in preferences (F12) enable "Remote Control" (port 8111)
- go to osmose in HTTPS: https://osmose.openstreetmap.fr
- click on any marker, then on "josm-zone" link

Expected results:
- the request is sent to JOSM to download OSM data

Observed results:
- the request is blocked. In console we see this warning (in French, sorry): "Blocage du chargement du contenu mixte actif (mixed active content) « http://localhost:8111/load_and_zoom?left=-0.4779639&bottom=43.830608299999994&right=-0.4739639&top=43.8346083&select= »"

Problem reported and discussed here: https://github.com/osm-fr/osmose-frontend/issues/111

Comment 4

[vincent.privat]

(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+

Comment 5

[Honza Bambas (:mayhemer)]

(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 6

[vincent.privat]

Hello,
We investigated further and found out it was in fact a change in our application causing this issue (change from mixed passive content to mixed active content), not a regression from Firefox. So whatever is the problem originally reported here, we're not affected.
Sorry for the noise,
Vincent

Comment 7

[Jonathan Kingston [:jkt] he/him]

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

[Simone Granata]

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

[Simone Granata]

(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

Comment 10

[Christoph Kerschbaumer [:ckerschb]]

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

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

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.

Comment 12

[Daniel Veditz [:dveditz]]

(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

[Honza Bambas (:mayhemer)]

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.

Comment 14

[Daniel Veditz [:dveditz]]

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

[Jonathan Kingston [:jkt] he/him]

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.

Comment 16

[Christoph Kerschbaumer [:ckerschb]]

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.

Comment 17

[timhigins]

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

[Guillaume Egles]

Any progress on this? It seems to work fine in Chrome and it would be great to have parity...

Cheers. G.

Comment 19

[Jonathan Kingston [:jkt] he/him]

The WIP patch in Bug 1220810 should address this issue.

Comment 20

[jonathan.moosheer]

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.

Comment 21

[Frédéric Wang (:fredw)]

Bug 1220810 landed ; localhost/ and *.localhost/ are treated as "Potentially Trustworthy" as described in https://w3c.github.io/webappsec-secure-contexts/#localhost

Comment 22

[Hamish Willee]

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