1390657 - Firefox Nightly Registers Service Worker in windows with insecure opener

Status: RESOLVED INVALID

(Core :: DOM: Service Workers, defect, P3)

Description

[Microsoft Vulnerability Research]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

Repro steps
Go to http://pentest.azurewebsites.net/open.php?url=https%3A%2F%2Fshhnjk.azurewebsites.net%2Fsw.html
Click on window.open link.
Service worker is registered in non-secure context.


Actual results:

Firefox Nightly registers Service Worker in non-secure context


Expected results:

Register Service Worker in secure context.

Comment 1

[Microsoft Vulnerability Research]

Acknowledgement:
Jun Kokatsu and Microsoft Vulnerability Research

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

We are compatible with chrome here at the moment.  There is some discussion as to whether we want an insecure opener to block the service worker from running on an https site.  For example, see bug 1341982.

John, what is our status on bug 1341982 and secure-context-with-insecure-opener?

Also, I'm not sure this needs to be a private bug or not.

Comment 3

[Jonathan Kingston [:jkt] he/him]

Sorry Ben, that bug is assigned to me however I haven't been working on it. I will ask if we want to prioritise this work going forward. The CSP work would likely fall into our teams work and we have people in the WebAppSec that can do spec work etc.

I think this is a known limitation that violates the specification with minimal security risk. :dveditz would be the ultimate decision maker on if it's security worthy however it was my understanding it was widely known.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Daniel, can we open this bug up?  Per comment 2 and comment 3 this is a known spec issue and its unclear what the final desired outcome will be.  Also, we currently match behavior with chrome here.

Comment 5

[Daniel Veditz [:dveditz]]

Yes, unhiding the bug. The opener condition in the spec is unintuitive and non-reciprocal. We probably want to change the spec rather than our behavior.

Comment 6

[Andrew Overholt [:overholt]]

Seems like something that needs to be fixed at the spec level first so P3.

Comment 7

[Jens Stutte [:jstutte]]

:perry, I do not see from this bug if we ever filed an issue to the spec. Can you check?

Comment 8

[Perry Jiang [:perry] [no longer employee, use ni?]]

I think this is no longer a bug. At the time this was filed, it appears that an insecure page opening a "secure" page would cause the "secure" page to actually be insecure, and ServiceWorkers are only permitted to be registered in secure contexts. However, it seems that the spec has changed to treat the "secure" page in such a situation actually as a secure page, e.g. example 4 at https://w3c.github.io/webappsec-secure-contexts/#examples-top-level. The function to register workers also does make a secure context check before it's available to use: https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/dom/serviceworkers/ServiceWorkerContainer.cpp#98.