Closed Bug 1488740 Opened 6 years ago Closed 4 years ago

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

Categories

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

61 Branch
defect

Tracking

()

RESOLVED FIXED
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.
Component: Untriaged → Networking: HTTP
Flags: needinfo?(hirschbeckdaniel)
Product: Firefox → Core
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.
Component: Networking: HTTP → Security
(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.
Component: Security → DOM: Security
See Also: → 903966
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.
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.
(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
Blocks: 903966
Flags: needinfo?(birunthan)
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.
Assignee: nobody → ckerschb
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(birunthan)
Priority: -- → P3
Whiteboard: [domsecurity-active]
(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
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.
Summary: Mixed content call to localhost → Stop treating "http://localhost/" (by name) as mixed content
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.
Depends on: 1295777

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.

See Also: → 1402530

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.

Assignee: ckerschb → nobody
Status: ASSIGNED → NEW
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]
See Also: → 1376309
See Also: → 1346835
See Also: → 1464998

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.

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

Cheers. G.

The WIP patch in Bug 1220810 should address this issue.

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.

Depends on: 1672323

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

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Depends on: 1673315
Blocks: 1295777, 1672323
No longer depends on: 1295777, 1672323
You need to log in before you can comment on or make changes to this bug.