1268323 - service workers should not control https iframes nested under insecure documents

Status: NEW

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

Description

[Ben Kelly [:bkelly, not reviewing]]

A user recently reported that they were able to:

0) Open https://bar.com, register a service worker, and then close the window.
1) Create an http://foo.com insecure window
2) Nest an https://bar.com secure iframe in that window
3) Get the nested iframe controlled by a service worker
4) Use the various postMessage() calls on these objects to communicate between insecure document and secure service worker.

The spec kind of doesn't allow this, but its also a bit vague.  See:

  https://github.com/slightlyoff/ServiceWorker/issues/890

I'm going to file this as a secure bug for now.  Ehsan and Andrea are discussing if it can be opened up.

Comment 1

[(no longer active)]

Hmm, so the risk vector here is the insecure parent page postMessage()ing to the nested secure iframe, and the nested secure iframe proxying the message to its service worker.  In theory it's possible for the parent page to send a message to the secure service worker that will confuse the service worker, or in case the nested secure page also proxies the messages from its service worker to its parent window, steal data coming from the response of the service worker to a message.  However, all of this requires cooperation from the secure iframe.  Furthermore, even if the parent page was a secure context the same vector would already exist, it's just that with an insecure parent a MITM agent can control the insecure parent page.

Still it's not obvious to me if this is a security bug or just a mere violation of exposing a powerful feature to an insecure context.  Daniel, what do you think?

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Ben reports that chrome has the same behavior.  I'm going to send them mail.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=607543

Jake's initial take on whether to keep it hidden:

"Yeah, an iframe in within an http page is not secure, so should not use a service worker. This is a security bug, but I don't think it's severe enough to be private."

Comment 4

[ben last]

For clarity - the secure iframe within the insecure page doesn't have access to `getRegistration()` (returns `undefined` in FF, rejects on Chrome) and can't register, unregister, etc. All that happens here is that fetch events within the scope of a *already registered worker* are intercepted. Emphasis intentional: in order for this to work, a service worker must already be registered for the secure domain serving the iframe source.

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to :Ehsan Akhgari (busy, don't ask for review please) from comment #1)
> Still it's not obvious to me if this is a security bug or just a mere violation of
> exposing a powerful feature to an insecure context.  Daniel, what do you think?

More the latter than the former.