iOS sporadically sends old cookies

Question

I have an application that rotates an auth token cookie values regularly.

Each time the server rotates the token, it will not mark it as "good" until it sees the client has the token (cause the client includes it in the request headers for a resource).

I have a very specific situation ONLY on iOS (10.3) where sporadically it will send a very old cookie when network conditions change (eg: get off the subway). When this condition hits it "forgets" about the most recent cookie value and "starts living in the past" and sends and old value.

^{** Security note: IP addresses are publicly allocated t-mobile in NYC and token has long been deleted from our DB}

• Is this a known issue?
• Are there any workarounds for cookie handling that is more robust on iOS? localstorage is not ideal cause these cookies are http only.

To clarify ... this is the flow:

1. Client (iOS Safari) has a cookie called _t with the value old
2. Client (iOS Safari) makes a request to the server
3. We issue Set-Cookie and set _t cookie to a new value new (http only, secure cookie)
4. Client makes another request with the new cookie value new. We flag that the cookie value is good and client has it.
5. Time passes
6. Client makes a request with the _t cookie with the value old

Answer 1

My experience

I also use authentication via IDs that change with each request and are stored in cookies. I can confirm this behavior and it is still present in iOS 11 (and iOS 11.1 beta 3). In my log files, I can see that sometimes old cookies are randomly stored in Safari. This happens in a standalone webapp when it is closed and reopened.

My Fallback method

I built a fallback method over localStorage. A request with an old cookie will normally mark all data in my database as invalid. If the user agent points to a device with iOS, I do not mark the data as invalid and give the client a second attempt to authenticate itself.

On the client side I check the localStorage and create new cookies with this data. Subsequently, a new authentication takes place. The localStorage is rewritten like the cookies with each request. If authentication fails again, I mark the data as invalid.

Answer 2

Here is my theory of what happened:

From the cookies lifecycle, whenever user authentication state change (login user -> logout user || logout user -> login user), the old cookie would be invalidated and replaced with a new cookie.

But why that happened in the subway and not other places?
1. These days most subways provide free unsecured WiFi to supplement the bad wireless network connectivity while underground.
2. There were some reports on network connectivity issue in 10.3, and this one in particular is interesting, as the issue was location dependent.
3. I think the combination of (1) and (2) above was causing the app to reauthenticate to the server. Maybe you could pull the logs to check if that is indeed the case?

Possible workaround?

Maybe none.
We can't prevent iPhone user from doing iOS upgrade. And most already did.
Also, the security repercussion of not changing cookies after reauthentication is worse.

Update based on the comment as of 05/31/2017:

Given the details as in the comment. We could have better explanation.

In cookie life cycle, when user logout, server-side-invalidation should take place.

The work flow:
1. When the user logout, the authenticated sessionID is deleted from the browser.
2. But that's not enough. The server needs to invalidate that sessionID too. Else there could be security repercussion.
3. It could be that in your case the server didn't invalidate. Thus it still expecting a SessionID which has been deleted from the browser.

This is just one possible explanation. To be exact, more details log file analysis and more experiment would be required.

For example, during that period, at the server log were there any reauthentication took place?
Could we test in a controlled environment, if the server-side-invalidation has been implemented properly?