Open Bug 1570243 Opened 4 months ago Updated 3 days ago

window.isSecureContext is incorrect in fission when child frame is https

Categories

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

defect

Tracking

()

ASSIGNED
Fission Milestone M5

People

(Reporter: enndeakin, Assigned: jkt)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

  1. Have an HTTP page with a child HTTPS iframe.
  2. 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:

  1. The detection of insecure login forms to display the insecure login UI is incorrect.
  2. 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
Fission Milestone: ? → M4
Priority: -- → P2
Priority: P2 → --

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).

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.

Flags: needinfo?(jkt)
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Priority: P3 → P2

This affects both the browser_hasInsecureLoginForms.js and browser_http_autofill.js tests with fission enabled.

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

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.

Flags: needinfo?(jkt)
Depends on: 1584157
Assignee: nobody → jkt
Status: NEW → ASSIGNED
Depends on: 1594529

Roll some unfixed bugs from Fission Milestone M4 to M5

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Fission Milestone: M4 → M5
You need to log in before you can comment on or make changes to this bug.