1476094 - webextensions: fetch API leaks cookies into user env

Status: RESOLVED INVALID

(WebExtensions :: Request Handling, defect)

Description

[Marcel Klehr]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/66.0.3359.181 Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce:

1. Fetch a web resource from inside a webextension using fetch API and Basic Auth.
2. The server sends cookies that represent the new session for the site.



Actual results:

3. In a normal browser tab, the user is now logged in to the site, without having entered their credentials.


Expected results:

The cookie jar of a webextension shouldn't be shared with the normal browsing session.

Comment 1

[u554753]

I'm not entirely certain if this is a Networking: Cookies related issue or a WebExtensions-related one. Please correct the component if this isn't the case. Thanks.

Comment 2

[u554753]

Hi Marcel, which WebExtension did you use in particular for this test?

Comment 3

[Marcel Klehr]

It turns out I can't reproduce this. My fault. I'm sorry for the disturbance.

Comment 4

[Marcel Klehr]

Actually, I can reproduce it now:

I'm the developer of floccus (available on AMO). It syncs bookmarks with nextcloud. When I clear all browser data and cookies and go to my nextcloud afterwards, I don't see any cookies being sent. However, if I clear the browser data, sync my bookmarks with the same nextcloud, and only after that access my nextcloud, I see the session data being transmitted in the browser console (network tab).

Comment 5

[u408661]

I believe we put cookies into jars based on originattributes. Sounds to me like, perhaps, the fetch api, when used within a webextension, isn't setting the originattributes correctly to shove these cookies in the proper jar, but that's just my best first guess. Putting in core/dom networking to get (what I hope are) the appropriate eyes on this.

Comment 6

[Valentin Gosu [:valentin]]

(In reply to Marcel Klehr from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
> Gecko) Ubuntu Chromium/66.0.3359.181 Chrome/66.0.3359.181 Safari/537.36
> 
> Steps to reproduce:
> 
> 1. Fetch a web resource from inside a webextension using fetch API and Basic
> Auth.
> 2. The server sends cookies that represent the new session for the site.

Can you provide a code example of how you are using fetch?
Are you using it in a content script, background script, etc?

Comment 7

[Valentin Gosu [:valentin]]

See question in comment 6

Comment 8

[Marcel Klehr]

Sure, the code of my extension is open source. Here is a link to the fetch call: https://github.com/marcelklehr/floccus/blob/master/src/lib/adapters/Nextcloud.js#L258

I haven't tested the problem after adding the credentials: 'omit' (which was added after Chrome changed the default from 'omit' to 'same-origin')
The code runs in a background script

Comment 9

[Valentin Gosu [:valentin]]

Moving to webextensions for now to determine:
1. if this is really a bug
2. the source of the bug (if we are not setting the proper originAttributes)
3. how it should be fixed

A test for the desired behaviour would be very helpful.

Comment 10

[Kris Maglione [:kmag]]

This is expected. It works the other way too: if a user logs into a site in a normal tab, requests from an extension contain those session cookies.

It would probably be nice to allow extensions to make requests associated with a particular container, but that's a separate bug.

Comment 11

[Marcel Klehr]

> if a user logs into a site in a normal tab, requests from an extension contain those session cookies.

Oh. From a security perspective I'm thinking it would probably make sense to have a more fine-granular permission system that allows making requests without automatically sending all available cookies along, and thus having access to all accounts of that user. This can cause a lot of side effects aside from being a very broad permission. Thanks for clearing this up, though. :)