Closed Bug 1729022 Opened 3 years ago Closed 3 years ago

SameSite Cookies leaked in cross-site request through service worker

Categories

(Core :: DOM: Service Workers, defect)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1658869

People

(Reporter: holegary, Assigned: edenchuang)

Details

(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(1 file)

2.43 KB, application/x-zip-compressed
Details
Attached file demo.zip

Summary

When cookies are configured to use lax and strict - these are sent through the service worker when made by a cross-site initiator. This leaks cookie information and goes against the security design principles of samesite cookies.

Setup instructions

You will need somewhere to host this code. Also PHP should be installed on the host so it can output the cookie information.

This can be setup locally and use "file://<path>/cross-site.html" as the cross-site initiator.

  1. Decide where you will host all of this code, and upload files to host.
  2. Download and edit "cross-site.html" changing references from "http://cc.local" to suit where you have hosted
  3. CRITICAL STEP: Visit the url you've setup e.g. "http://cc.local/index.php" - this will allow the service worker to install. Ensure service worker was registered in DevTools (should be scoped under "sw-echo"). If your hosting this locally, the service worker may not install without HTTPS.
  4. Run "cross-site.html" locally in your browser (file://) or upload to another domain where you can load it - the key is that it must be on a different domain so it issue's cross-site requests.
  5. You should see all the various buttons to test with

Note: If you can't host via HTTPS, the service worker may not install for security reasons. You can try whitelisting the domain, e.g. using "--unsafely-treat-insecure-origin-as-secure=http://cc.local" launch parameter flag in Chrome.

How it works

When the buttons are pressed, it should make a cross-site request as per below:

  • POST: With sw - makes a POST request and the scoped service worker under (sw-echo) will make the fetch request
  • POST: Without sw - doesn't use the service worker at all, standard browser POST
  • GET: With sw - as above, but uses a GET request
  • GET: Without sw - as above, but uses a GET request
  • Link - a standard link to a cross-site

What is the vulnerability?

With both POST and GET requests with the SW it will send strict, lax and none cookies.

What's the expected behaviour?

For POST requests, it's expected only "none" cookie should be sent, as it's a cross-site request.
For GET requests, it's expected only "lax" and "none" cookie should be sent.

How severe is this vulnerability?

I would suggest it's pretty serious, especially considering it's vulnerable even for GET requests

Flags: sec-bounty?

Moving to the "Service Workers" component on the theory that it's not telling networking the correct origin for these requests. Could be a networking::Cookies issue instead though.

Group: firefox-core-security → dom-core-security, core-security
Type: task → defect
Component: Security → DOM: Service Workers
Keywords: sec-high
Product: Firefox → Core
Assignee: nobody → echuang

Thanks for providing the demo case. After analyzing the case, I believe this is a duplicate of bug 1658869.

The possible reason is the origin of fetch request in service worker is not set correctly. However, we had some thought on that if it is a spec issue or not? But this might be a follow-up step.

Now, I would like to modify our implementation to follow the spec first. If the spec is modified through the PR, we will modify it back again.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Group: core-security
Flags: sec-bounty? → sec-bounty-
Keywords: sec-high
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: