Closed Bug 1650839 Opened 5 years ago Closed 4 years ago

Setting cross-origin cookies via fetch

Categories

(Core :: DOM: Networking, defect)

Product:
Core
Component:
DOM: Networking
Version:
78 Branch
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: pmhsfelix, Unassigned)

References

(Blocks 2 open bugs)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15

Steps to reproduce:

Did a fetch from origin https://example.net to https://httpbin.org, with 'credentials' set to 'include' and Enhanced Tracking Protected set to "strict".

Actual results:

The Set-Cookie in the response from https://httpbin.org was processed and the cookie was stored, even if it is a third-party cookie (the origin doing the request is https://example.net). Namely, subsequent requests to https://httpbin.org do forward the cookie.

Expected results:

The Set-Cookie should have been ignored to avoid tracking by the third-party (https://httpbin.org in this case). This is the behaviour I get with Safari and that I was expecting with Firefox, having Enhanced Tracking Protected fully enabled.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → DOM: Networking
Product: Firefox → Core

Honza, can you take a look, or sending tto someone who can take a look?

Flags: needinfo?(honzab.moz)

I created a test based on the description on my local test server accessible by two different origins
with ETP at strict:

Nightly (80)

2020-07-16 17:40:55.558000 UTC - [Parent 12596: Main Thread]: W/cookie ===== COOKIE NOT ACCEPTED =====
2020-07-16 17:40:55.558000 UTC - [Parent 12596: Main Thread]: W/cookie request URL: http://test.local2/bugs/1650839/response.txt
2020-07-16 17:40:55.558000 UTC - [Parent 12596: Main Thread]: W/cookie cookie string: test=1; max-age=999999; path=/
2020-07-16 17:40:55.558000 UTC - [Parent 12596: Main Thread]: W/cookie current time: Thu Jul 16 17:40:55 2020 GMT
2020-07-16 17:40:55.558000 UTC - [Parent 12596: Main Thread]: W/cookie rejected because failed the samesite tests

Release (78.0.2)

2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie ===== COOKIE ACCEPTED =====
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie request URL: http://test.local2/bugs/1650839/response.txt
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie cookie string: test=1; max-age=999999; path=/
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie replaces existing cookie: true
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie current time: Thu Jul 16 17:52:23 2020 GMT
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie ----------------
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie name: test
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie value: 1
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie host: test.local2
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie path: /
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie expires: Tue Jul 28 07:39:02 2020 GMT
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie created: Tue Jul 07 17:39:24 2020 GMT
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie is secure: false
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie is httpOnly: false
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie sameSite: none - rawSameSite: none
2020-07-16 17:52:23.024000 UTC - [Parent 27256: Main Thread]: D/cookie origin attributes: {empty}

So, this is something recently fixed. Baku, any idea?

Flags: needinfo?(honzab.moz) → needinfo?(amarchesini)

So, this is something recently fixed. Baku, any idea?

In nightly we are testing dFPI (cookieBehavior 5). We should run the test with cookieBehavior 4 to have the same behavior as firefox 78.
I keep the NI and I run a couple of tests to give a proper answer tomorrow.

I suspect I know the answer without checking it too much. Can you answer the following questions?

  1. do you pass a sameSite attribute when running the test? In nightly, we are testing sameSite=lax by default. Because of that, the cookie is rejected because a 3rd-party resource cannot set a sameSite=lax/strict cookie. This doesn't happen in 78.

  2. Why should httpbin.org be blocked? httpbin.org is not considered a tracker in firefox. You can check it using about:url-classifier. In 'strict' mode, we do not block all the 3rd party cookies, but only what is in the strict disconnect.me lists. If you want to have similar behavior as safari, I suggest using dFPI (dynamic-first-party-isolation).

With dFPI, we accept the cookie from httpbin.org (ignoring the issue related to the sameSite attribute), but we double-key it with 'example.net'.

Flags: needinfo?(amarchesini) → needinfo?(pmhsfelix)

Regarding your questions:

  1. No, I don't think so. The third-party (i.e. http.bin) cookie set is just: set-cookie: x=y; Path=/
    The complete response
    HTTP/2 302 Found
    date: Mon, 20 Jul 2020 11:26:13 GMT
    content-type: text/html; charset=utf-8
    content-length: 223
    server: gunicorn/19.9.0
    location: /cookies
    set-cookie: x=y; Path=/
    access-control-allow-origin: http://example.net
    access-control-allow-credentials: true
    X-Firefox-Spdy: h2

  2. I was assuming, probably incorrectly, that under "Enhanced Tracking Protection - Strict", all third-party cookies are disabled. Namely because that is the behaviour I get on Safari and Brave. That is why I was expecting httpbin.org to be blocked as well (which I'm using just for testing purposes).

I'm doing this while researching an HTTP API feature that could use third-party cookies for short term session management. In this context, I wanted to understand the cookie behaviour of different browsers and was surprised by Firefox's behaviour.
Where can I read more about dynamic-first-party-isolation

Flags: needinfo?(pmhsfelix)

The severity field is not set for this bug.
:nhi, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(nhnguyen)
Flags: needinfo?(nhnguyen) → needinfo?(agrover)

Stephen, could you take a look at comment 6 and let us know if that's the correct behaviour? Thanks!

Flags: needinfo?(agrover) → needinfo?(senglehardt)

I was assuming, probably incorrectly, that under "Enhanced Tracking Protection - Strict", all third-party cookies are disabled. Namely because that is the behaviour I get on Safari and Brave. That is why I was expecting httpbin.org to be blocked as well (which I'm using just for testing purposes).

We do not block all third-party cookies in the Strict mode of ETP. At the time of your report, the main difference between the Strict mode and Standard mode was whether we enabled resource blocking based on a blocklist of trackers. That's still true, but we additionally enable dFPI in Strict mode as of Firefox 86 which doesn't block third-party cookies and instead partitions them.

Where can I read more about dynamic-first-party-isolation

You can check out our state partitioning MDN page.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #8)

Stephen, could you take a look at comment 6 and let us know if that's the correct behaviour? Thanks!

I can confirm this is expected.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(senglehardt)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.