Bug 200345 - SameSite cookies missing after Safari Tab recovery
Summary: SameSite cookies missing after Safari Tab recovery
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 200307 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-08-01 08:03 PDT by Chris Dumez
Modified: 2021-07-08 16:25 PDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2019-08-01 08:03:00 PDT
SameSite cookies missing after Safari Tab recovery.

Demo: https://rocky-fjord-97287.herokuapp.com

1. Load the page on iOS
2. Click the "Refresh Cookie Time" button
3. Reload the page a couple times and notice that the cookie time is there and does not change (cookie is served)
4. Kill MobileSafari
5. Relaunch MobileSafari
6. Reload the tab a couple times and notice that the cookie is nil for every reload (cookie is no longer served).

Reported on Twitter by Rafael Silva (@Rafael_falco).
Comment 1 Chris Dumez 2019-08-01 08:03:48 PDT
Service workers are involved as well. Here is the source:
https://github.com/xfalcox/safari-sw-samesite-bug
Comment 2 Radar WebKit Bug Importer 2019-08-01 08:06:28 PDT
<rdar://problem/53814606>
Comment 3 Alexey Proskuryakov 2019-08-02 13:32:30 PDT
*** Bug 200307 has been marked as a duplicate of this bug. ***
Comment 4 Rafael 2019-08-06 12:56:58 PDT
I can repro this bug on latest Mac OS Safari (12.1.1) if you enable the feature to re-open the last tabs on app start.

So this seems to affect both Mac OS and iOS on both current and next Safari.
Comment 5 Bradley Ayers 2021-07-08 16:25:07 PDT
I've been investigating a similar issue, but this one's related to SameSite strict and WebSockets.

Reproduction steps:

1. Given a site (e.g. site-a.com) with page that:

  - sets a SameSite strict cookie (`MyStrictCookie`).
  - sets a SameSite lax cookie (`MyLaxCookie`).
  - makes an XHR request to the same domain (e.g. `/api`).
  - makes a WebSocket request to the same domain (e.g. `/ws`).

2. Expected behavior scenario:

  1. Load the page by typing in the URL and pressing Enter.

    - In Web Inspector > Storage > Cookies, both `MyStrictCookie` and `MyLaxCookie` are visible.
    - In Network > XHR, the request sends `MyStrictCookie` and `MyLaxCookie`.
    - In Network > Other, the WebSocket request sends `MyStrictCookie` and `MyLaxCookie`.

3. Problematic behavior scenario:

  1. Close the window.
  2. Restore the window via History > "Reopen Last Closed Window".

    - In Web Inspector > Storage > Cookies, only `MyLaxCookie` is visible (`MyStrictCookie` is missing).
    - The Network > XHR, the request sends `MyStrictCookie` and `MyLaxCookie`.
    - The Network > WebSocket, the WebSocket request only sends `MyLaxCookie` (`MyStrictCookie` is missing).

  Other notes worth mentioning:

  - This behavior affects all tabs in a re-opened window. However new tabs created in that window are not affected.
  - If you "Duplicate Tab" from the tab's context menu, the new tab will exhibit the same behavior as the duplicated tab (i.e. it inherits some security tainting).
  - It seems incorrect that the XHR request sends `MyStrictCookie`, yet the cookie is not visible in Web Inspector > Storage. I'd expect consistency between the two.
  - Further more, the inconsistency of having `MyStrictCookie` sent for XHR but not for WebSocket seems incorrect. I'd expect it to be sent for both, or sent for neither. And playing off the previous point, given the cookie isn't visible in Web Inspector, I expected neither.
  - The tab can be "fixed" by focusing the location bar with the URL and pressing enter. Presumably because this causes a "top level navigation", and pages loaded via top level navigation always have access to SameSite strict cookies.
  - The tab behavior can be reproduced by creating a tab via `window.open('site-a.com')` from a different domain. My understanding is this simply following the SameSite spec. Is it possible that tabs in a "re-opened window" are created using a similar mechanism, and it's for that reason that they don't satisfy the SameSite strict checks, and the tabs are tainted as "not trusted".