[Webkit-unassigned] [Bug 272325] New: Session cookies being reset rendomly

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 8 05:40:13 PDT 2024


            Bug ID: 272325
           Summary: Session cookies being reset rendomly
           Product: WebKit
           Version: Safari 17
          Hardware: iPhone / iPad
                OS: iOS 17
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: Website Storage
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ricardo.cristino at outsystems.com
                CC: sihui_liu at apple.com


My company provides a low-code platform used by a large number of companies around the world. We have applications running on all the major browsers, PWAs, native Android, and native iOS. Recently, a few customers who upgraded iOS (from what we could determine, to iOS 17.2 - 17.4.1) have reportted that the session cookies were getting lost in PWAs and native apps. We also have similar reports on Edge 123.0.2420.56 and lower versions. Considering that this misbehavior can be replicated in the simplest applications, we are concerned that more customers will become affected.

The authentication flow of all applications shares the same flow:
1. A user accesses an application for the first time;
2. The server replies with two set-cookie headers which define two persistent cookies with default values (let's call them cookies A and B);
3. These two cookies are always sent together with the "Cookie" header in the subsequent requests;
4. The user logs in and the server replies with three Set-Cookie headers: cookies A and B are changed to different unique values with session expiration; and a third session cookie C is also created/modified;
5. Here, the user is authenticated, those 3 cookies are passed in the "Cookie" header to authenticate any request to the server. 

The observed issue is that after the login, having already three session cookies, we suddenly detect that the "Cookie" header contains values different than the ones set after the login. Cookies A and B no longer have a session value but, instead, were reset to the persistent default value obtained in step 2. Cookie C still has the same session value. An important detail is that document.cookie has the expected cookie values. This causes the authentication to fail and the users lose their session randomly.

Note that the application javascript is not interfering with the cookies (some are HTTPOnly which forbids javascript from accessing them). We placed traces everywhere on the backend and proved that the server never replied with a set-header cookie from the instant the login happened to the instant the cookies changed. So, only some underlying iOS mechanism could be switching valid session cookies by others which were set several requests back. We made some investigation and came across multiple threads reporting behaviors and findings extremely similar to ours:
https://bugs.webkit.org/show_bug.cgi?id=255524 (supposedly resolved but with comments from developers suggesting the behavior is still happening in supposedly fixed versions)

Being no experts on iOS, we can't tell if those issues have the same underlying cause. But given that this issue is happening even in the latest iOS 17.4.1 version, we can say that it has not been resolved yet.

We can replicate the issue on a PWA installed on iPad 17.4.1 with the default browser Safari:
1. After close/reopen the PWA, we confirm that session cookies A and B are automatically reset to the persistent default ones. Cookie C still has the same session value as before closing the app.
2. Then we login, get new session values for all three cookies;
3. We navigate through the app, making some requests to the server.
4. Sometimes we lose the session, others don't.
5. When we don't lose the session, we start over from 1. until it happens.

If we change to the default browser (e.g. Chrome), we can't replicate the issue anymore on the PWA. It is interesting to note that we no longer lose the session simply by closing and reopening the app. If we revert the default browser to Safari, the issue does not replicate and the session is not lost once we close and reopen the app. We have to clear the History and Cookies for the behaviors to reappear again.

We played with Same Site, switching it from None to Lax, unchecked Prevent Cross-Site Tracking, generated a native iOS app instead of using the PWA, etc. All these tests did not mitigate the issue.

For testing purposes, we modified our backend not to send a set-cookie C header in any response. Without cookie C on the app, this issue is much harder or impossible to replicate. Curiously, this is the only cookie that is just set as session and never as persistent.

In another test, we set cookies A, B, and C as persistent instead of session. We could not replicate the issue based on our tests. 

Keep in mind that we can't be sure if other tests made in different devices and circumstances would produce the same results. So, don't take these results for granted.

Having said this, we can't change our entire authentication mechanism. It is also difficult to ask all iOS users to install Chrome. So, we kindly request your cooperation in fixing this issue.


You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240408/0f3eeded/attachment.htm>

More information about the webkit-unassigned mailing list