Cross-site cookies handled differently for localhost origins between WebSocket handshake connections and other connections
Categories
(Core :: Networking: Cookies, defect, P2)
Tracking
()
People
(Reporter: birtles, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
2.52 KB,
application/zip
|
Details |
I'm sorry, I'm really out of my depth here and I've yet to work out how to create useful STR for this but what I am observing is the following:
With the following actors:
- Origin
- a.example.com
- b.example.com
I am observing the following behavior:
- Origin makes a CORS fetch request to
https://a.example.com
which responds with:
Set-Cookie: __Secure-sess=xyz; Max-Age=7776000; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=None
- Origin tries to connect to
wss://b.example.com
When Origin is localhost
or https://192.168.0.2
etc. Cookie
is not included in the request headers sent to wss://b.example.com
as part of the Web socket handshake.
However, when attempting to fetch https://a.example.com/path
with credentials: 'include', mode: 'cors'
the cookies are included.
This seems inconsistent to me?
By comparison, Chrome includes cookies in both cases (the DevTools do not show the cookie, since it is HTTP-only, but it is received by the server).
Furthermore, if Origin is c.example.com
, then the cookie is included.
Comment 1•4 years ago
|
||
(In reply to Brian Birtles (:birtles) from comment #0)
I'm sorry, I'm really out of my depth here and I've yet to work out how to create useful STR for this but what I am observing is the following:
With the following actors:
- Origin
- a.example.com
- b.example.com
I am observing the following behavior:
- Origin makes a CORS fetch request to
https://a.example.com
which responds with:
Set-Cookie: __Secure-sess=xyz; Max-Age=7776000; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=None
- Origin tries to connect to
wss://b.example.com
When Origin is
localhost
orhttps://192.168.0.2
etc.Cookie
is not included in the request headers sent towss://b.example.com
as part of the Web socket handshake.However, when attempting to fetch
https://a.example.com/path
withcredentials: 'include', mode: 'cors'
the cookies are included.This seems inconsistent to me?
By comparison, Chrome includes cookies in both cases (the DevTools do not show the cookie, since it is HTTP-only, but it is received by the server).
Furthermore, if Origin is
c.example.com
, then the cookie is included.
Could you provide a simple test case to demonstrate this issue? Thanks.
Reporter | ||
Comment 2•4 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #1)
Could you provide a simple test case to demonstrate this issue? Thanks.
Hi Kershaw, as you are aware, this issue involves three different servers so it's quite involved to create a simple test case.
I suspect someone familiar with this code could fairly quickly determine where we determine which cookies to include in a WebSocket handshake request and compare that with the codepath for a CORS fetch with credentials.
However, if you can point me to where we mock server responses including WebSocket responses (along with testing HTTP-only cookies) in web-platform-tests I might be able to create an automated test case.
Comment 3•4 years ago
|
||
Sorry for the delay here.
Since I am not quite familiar with the cookie code, could you try to get a http log that demonstrates this issue?
Thanks.
Reporter | ||
Comment 4•4 years ago
|
||
Thanks for getting back to me. Unfortunately I no longer have the environment needed to recreate this issue and there are probably several hours of work involved in getting it set back up. If I ever manage to set it up again I'll be sure to grab an HTTP log.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
I assume the problem is when comparing https://a.example.com
with wss://b.example.com
- Since it's a secure cookie, it takes the scheme into account, but https
and wss
don't match.
Reporter | ||
Comment 6•4 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)
I assume the problem is when comparing
https://a.example.com
withwss://b.example.com
- Since it's a secure cookie, it takes the scheme into account, buthttps
andwss
don't match.
That makes sense, except that it sends the cookie when connecting from https://c.example.com
so this appears to only affect the cross-site case.
I'm assuming we don't have anyone to replicate the environment to recreate this issue.
Valentin, do we have enough info to link this to schemeful samesite cookies?
Schemeful appears to have been created/enablde 4 years ago and disabled a year ago.
If it makes sense, we could probably prioritize this with schemeful-samesite (probably should be p3 if it's not already)?
I'm not sure this bug is related to same-site cookies.
I wrote this test case, and it seems when loaded from "http://other.localhost" the cookie isn't sent for the WS connection, but it is when it's loaded from "http://localhost".
I'm seeing the same behaviour in Chrome.
Not sure if it matches the reported scenario in comment 0, or if this actually needs HTTPS.
Reporter | ||
Comment 9•5 months ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #8)
Created attachment 9405226 [details]
testcase.zipI'm not sure this bug is related to same-site cookies.
I wrote this test case, and it seems when loaded from "http://other.localhost" the cookie isn't sent for the WS connection, but it is when it's loaded from "http://localhost".I'm seeing the same behaviour in Chrome.
Not sure if it matches the reported scenario in comment 0, or if this actually needs HTTPS.
I'm afraid I don't have the setup to test this anymore. It was using AWS API Gateway (HTTP API + WS API) so all the connections were over HTTPS and I noticed I was receiving the cookies as part of the handshake request in Chrome but not in Firefox. Furthermore, the cookies were only missing when the origin was localhost.
It's possible Chrome has changed since then to match Firefox or it's possible that HTTPS is required to reproduce the issue. In the end I believe I just switched to using manual session management to work around the issue.
Sorry I can't help reproduce this at the moment.
Description
•