1162018 - Cross origin URL leakage by fetch event handler of service worker

Status: VERIFIED FIXED

(Core :: DOM: Service Workers, defect)

Description

[Muneaki Nishimura]

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

Steps to reproduce:

1) Launch https://mallory.csrf.jp/sw/ and reload the page.
2) See the console log



Actual results:

The page opened by 1) tries to load https://gmail.com/ with <img> tag and it's HTTP request is captured by the fetch event handler in the service worker (https://mallory.csrf.jp/sw/service-worker.js).
Then, the parameter of the handler event.request.url contains the detailed URI of other origin, google.com, it's shown after redirect.

The actual URI retrieved from google.com can be shown by the console.log like this:
"Got the detailed URI of other origin --> https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=default&ltmplcache=2&emr=1&osid=1"
It can be used by a malicious attacker to get visitor's confidential/sensitive information contained in the URL.


Expected results:

The detailed URI of cross origin after redirect should not be contained to event.request.url.

Comment 1

[Muneaki Nishimura]

This issue is sometimes difficult to reproduce on my environment.
I found more stable way to reproduce on the latest Nightly, Windows 8.

1. Create new profile
2. Open about:config, and set devtools.webconsole.filter.serviceworkers;true.
   This setting is to show console.log of the service workers to the web console.
3. Launch https://mallory.csrf.jp/sw/ , then you can see the message 
   "Please reload this page to allow the service worker to handle network operations."
4. Reload the page, and then you can see the message
   "The service worker is successfully set."
5. Open the menu button and push "New Non-e10s" button, then a new e10s window is shown
6. Open https://mallory.csrf.jp/sw/ on the e10s window and reload.
7. See the web console on the e10s window opened at 5.
8. You can find
" Got the detailed URI of other origin --> https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=default&ltmplcache=2&emr=1&osid=1"

Comment 2

[Muneaki Nishimura]

I could reproduce the issue by the Nightly on Windows 8 and OSX Yosemite 10.10.3.
If you couldn't please try to remove the service worker, binded to https://mallory.csrf.jp, by about:serviceworkers.

Comment 3

[Muneaki Nishimura]

Note that not only "event.request.url" but also "response.url" has same potential.

Comment 4

[(no longer active)]

If I'm reading the spec correctly, we seem to not handle the step 4.3.4.10.1 of the fetch spec correctly...

"If the CORS flag is set and locationURL's origin is not request's url's origin, set request's origin to an opaque identifier."

Comment 5

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

The CORSListenerProxy deals with resetting the source origin https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCORSListenerProxy.cpp#757
Are we bypassing this when using SW?

Comment 6

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

The problem seems to be we don't perform step 4.3.3.2 or equivalent " Set request's skip service worker flag. ", because the call to fetch() in the SW should set the skip SW flag, which means any redirects etc. that happen should not go through the SW again. Josh, after the handle fetch call, we should set ForceNoIntercept() and any new channels created should inherit it. What is the best place to put those calls? It seems this escaped unnoticed because Bug 1137287 hadn't been fixed before, so redirection always failed.

Comment 7

[Josh Matthews [:jdm]]

I believe the patch in bug 1157283 should fix this, based on comment 6.

Comment 8

[Josh Matthews [:jdm]]

Well, presumably we'll still need to call ForceNoIntercept, but the addition to SetupReplacementChannel in bug 1157283 should make that propagate to any subsequent channels.

Comment 9

[(no longer active)]

FWIW I have disabled service workers on Nightly and Aurora until this and bug 1164397 get fixed.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Would this still affect 39 (with or without the fix in bug 1157283)?  39 will be released on beta next week.

Comment 11

[Josh Matthews [:jdm]]

ServiceWorkers aren't enabled on 39, so I don't believe we're concerned about this.

Comment 12

[Josh Matthews [:jdm]]

I am having troubles reproducing this. Here is my console output:

>Handling fetch event for "https://mallory.csrf.jp/sw/" service-worker.js:26:3
>" Got the detailed URI of other origin --> https://mallory.csrf.jp/sw/" service-worker.js:36:11
>"  Response for https://mallory.csrf.jp/sw/ from network is: " [object Response] service-worker.js:39:13
>
>Handling fetch event for "https://mallory.csrf.jp/sw/metaredirect.html" service-worker.js:26:3
>" Got the detailed URI of other origin --> https://mallory.csrf.jp/sw/metaredirect.html" service-worker.js:36:11
>"  Response for https://mallory.csrf.jp/sw/metaredirect.html from network is: " [object Response] service-worker.js:39:13
>Load denied by X-Frame-Options: https://www.google.ca/?gfe_rd=cr&ei=UfxlVbLxGOSM8Qey1ID4DQ does not permit cross-origin framing. <unknown>

Maybe the X-Frame-Options addition is new and is busting this testcase?

Comment 13

[(no longer active)]

I rewrote the original test case as an automated test.  It seems like bug 1137287 has indeed fixed this by setting the skip SW flag properly.  The service worker now doesn't see the redirected request at all.

I'll submit my test here.

Comment 14

[(no longer active)]

Attachment: Add an automated test to ensure that a redirected Request won't be visible to a service worker if it had triggered the original fetch()

Comment 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b485fe97c048

Comment 16

[Andrei Vaida [:avaida]]

Reproduced the bug on an affected build: 41.0a1 (2015-05-06), using the steps from Comment 1.

This is verified fixed on Firefox 41.0b8 (20150907144446), using Windows 7 x64, Ubuntu 14.04 x86 and Mac OS X 10.10.4, with dom.serviceWorkers.enabled;true. The console logs are no longer leaking the URL.