Open Bug 1696326 Opened 4 years ago Updated 5 months ago

Cross-site cookies handled differently for localhost origins between WebSocket handshake connections and other connections

Categories

(Core :: Networking: Cookies, defect, P2)

defect

Tracking

()

People

(Reporter: birtles, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

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:

  1. 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
  2. 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.

(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:

  1. 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
  2. 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.

Could you provide a simple test case to demonstrate this issue? Thanks.

Flags: needinfo?(brian)

(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.

Flags: needinfo?(brian) → needinfo?(kershaw)

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.

Flags: needinfo?(kershaw) → needinfo?(brian)

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.

Flags: needinfo?(brian)
Severity: -- → S3
Component: Networking: WebSockets → Networking: Cookies
Priority: -- → P2
Whiteboard: [necko-triaged]

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.

Blocks: cookie

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

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.

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)?

Flags: needinfo?(valentin.gosu)
Attached file testcase.zip

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.

Flags: needinfo?(valentin.gosu) → needinfo?(brian)

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

Created attachment 9405226 [details]
testcase.zip

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.

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.

Flags: needinfo?(brian)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: