window.isSecureContext is incorrect in fission when child frame is https
Categories
(Core :: DOM: Security, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox78 | --- | fixed |
People
(Reporter: enndeakin, Assigned: mattwoodrow)
References
(Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-backlog1])
Attachments
(3 files)
- Have an HTTP page with a child HTTPS iframe.
- The iframe's window.isSecureContext should return false, but when fission is enabled, it returns true.
This issue has two implications for the login manager:
- The detection of insecure login forms to display the insecure login UI is incorrect.
- The test browser_http_autofill.js , for example, verifies that http logins do not get filled into insecure context. The checks for isSecureContext are within InsecurePasswordUtils.jsm
Updated•5 years ago
|
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Does that mean all the mixed-content-blocker stuff is broken as well? I'm thinking of the inverse, of an https parent with an https frame that tries to navigate to an http page (I assume an initial http frame src would be blocked from loading by the parent frame without getting into this problem).
Comment 2•5 years ago
|
||
Jonathan, if that is a problem, than (as discussed) most likely our mixed content blocker implementation is also affected. Can you flip the pref and run all tests within dom/security/mixedcontent (and potentially wpt tests as well)?
I would imagine that there is some API that fission uses to query that information. Currently we most likely just stop traversing docshells when we hit the end of it - which in that case is the iframe.
Updated•5 years ago
|
Reporter | ||
Comment 3•5 years ago
|
||
This affects both the browser_hasInsecureLoginForms.js and browser_http_autofill.js tests with fission enabled.
Comment 4•5 years ago
|
||
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #2)
Jonathan, if that is a problem, than (as discussed) most likely our mixed content blocker implementation is also affected. Can you flip the pref and run all tests within dom/security/mixedcontent (and potentially wpt tests as well)?
I would imagine that there is some API that fission uses to query that information. Currently we most likely just stop traversing docshells when we hit the end of it - which in that case is the iframe.
All of the security/manager/ssl/tests/mochitest/mixedcontent/ tests are failing with fission, they are marked as skipped in the Fission Mochitests spreadsheet.
Comment 5•5 years ago
|
||
So I was able to replicate the issue with the MCB code and I was looking into that, in few places we are traversing docshells and checking if the document is secure, the issue with that in post fission is we don't have access to the docshell.
So I'm experimenting currently by using BrowsingContext fields to allow each docshell to update the browsing context for when it's https or not. This then should actually simplify lots of the code as we just then traverse the browsingcontexts rather than additionally checking if we have a mixedContent channel.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 6•5 years ago
|
||
Comment 7•5 years ago
|
||
Roll some unfixed bugs from Fission Milestone M4 to M5
0ee3c76a-bc79-4eb2-8d12-05dc0b68e732
Comment 8•5 years ago
|
||
Moving to M4.1 since it blocks some mochitests-fission.
Comment 11•5 years ago
|
||
Temporarily reassigning these DOM Security Fission bugs to ckerschb for re-triage.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 12•5 years ago
|
||
Depends on D73996
Assignee | ||
Comment 13•5 years ago
|
||
Depends on D73997
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
bugherder |
Comment 16•5 years ago
|
||
Comment 17•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Description
•