Partitioned cookie not sent from WebWokers
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox127 | --- | fixed |
People
(Reporter: sathupadi.kaushik, Assigned: timhuang)
Details
Attachments
(2 files)
Steps to reproduce:
Setup:
Consider two domains domain1.com and domain2.com.
- domain1.com/index.html hosts a html page that iframes domain2.com/index.html
- domain2.com/index.html sets a cookie (say Cookie1=test)
- domain2.com/index.html has two javascript files
-- index.js (included as a script tag in html)
-- webworker.js (run as a webworker)
Actual results:
Problem:
-
When index.js makes a fetch() call to domain2.com the cookie (Cookie1 is sent). This is working as expected since this cookie is partitioned with domain1.com and expected to be sent.
-
When webworker.js makes a fetch() call to domain2.com the cookie not sent.
Other notes: Cookie is set as SameSite=None, Secure=true. The cookies are set from the server side as response headers (not in javascript).
Expected results:
When Webworker.js makes a fetch() call the cookie should be sent just like a call from index.js. webwoker should not behave differently IIUC.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
Hey, thanks for reporting this!
If possible could you please provide the following information?:
- The code you used to reproduce this / a demo site.
- The console logs when this happens.
- Your Browser Privacy -> Enhanced Tracking Protection settings.
|
Reporter | |
Comment 3•2 years ago
|
||
Enhanced Tracking Protection=Standard
You can reproduce this by going to : https://domain1-rgyfxmsibq-wl.a.run.app/
Expectation: both cookie response from js and webworker should be: "1234", but only the fetch request from js sends the cookie correctly, webworker does not.
Note: I will bring down hosting after a few days. You can always reproduce this with the following files.
domain1.com/index.html looks like this:
<iframe src=" https://domain2.com" width="100%" height="100%"></iframe>
domain2.com/index.html looks like this:
<!DOCTYPE html>
<html>
<head>
<script src="/main.js"></script>
</head>
<body>
<h1>Cookie response from js: <span id="from-js"></span></h1>
<h1>Cookie response from worker: <span id="from-worker"></span></h1>
</body>
</html>
domain2.com/main.js looks like this:
fetch("/read")
.then(response => response.text())
.then(data => {
console.log("Cookie response from script:" + data);
document.getElementById("from-js").innerHTML = data;
});
window.addEventListener('load', () => {
console.log("Worker started");
const worker = new Worker('/webworker.js');
worker.onmessage = (event) => {
console.log(`Cookie response from web worker: ${event.data}`);
document.getElementById("from-worker").innerHTML = event.data;
};
worker.postMessage("get");
});
domain2.com/webworker.js looks like this
onmessage = (event) => {
fetch('/read')
.then(response => response.text())
.then(data => postMessage(data));
};
|
Assignee | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 4•2 years ago
|
||
You might also want to see the server side code that sets the cookies. That is pretty simple, but I'll just paste it here for completeness.
server.js
app.get('/', (req, res) => {
res.cookie('abcd', '1234', { sameSite: 'none', secure: true });
res.render('index');
});
app.get('/read', (req, res) => {
const cookie = req.cookies.abcd || 'notfound';
console.log(cookie);
res.send(cookie);
});
root (/) sets the cookie and "/read' is called from both webworker.js and main.js as described above.
|
|
Assignee | |
Comment 5•2 years ago
|
||
The targetBrowsingContext is not available for fetch requests from
worker scopes. So, we cannot get the target browsing context in
ShouldAllowAccessFor().
To fix this, we can use the WorkerAssociatedBrowsingContext if the target
browsing context is not available.
|
|
Assignee | |
Comment 6•2 years ago
|
||
The patch updates the wpt
requestStorageAccess-dedicated-worker.tentative.sub.https.window.js
which assumed the worker inherits storage access from its parent.
However, workers shouldn't inherit storage access from the parent
because storage access is restricted to the frame where requests storage
access..
We also update the ini file for the test.
Depends on D208757
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 9•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/18b91cc49e30
https://hg.mozilla.org/mozilla-central/rev/c13bf5bee99b
Description
•