11

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.

log

** 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
Sam Saffron
  • 128,308
  • 78
  • 326
  • 506

4 Answers4

3

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?

Wismin
  • 1,135
  • 7
  • 21
  • there is no app involved here, this is a standard website using iOS, the server sets the cookie using `Set-Cookie` header. Client makes a second request, and echos that it has the cookie. Hours later it ship an older cookie. – Sam Saffron May 31 '17 at 20:37
  • the answer has been updated in response to the comment. – Wismin May 31 '17 at 21:19
  • note, this was a straight out bug in iOS and is resolved now. – Sam Saffron Mar 19 '18 at 10:56
  • 1
    I’m not sure if this is the same case, but I’ve noticed a similar issue involving an ios device from a user of our web app. I still need to investigate further but looking at logs, it almost seems like this user’s safari browser is randomly reusing an old cookie with stale information because the requests show such a pattern. User agent shows an ios device with 11.4 though – georaldc Sep 13 '18 at 20:48
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.

daniel
  • 21
  • 3
0

Safari View Controller no longer shares cookies with Safari in iOS 11 and up, this change resolved the cookie store corruption issues that plagued iOS. We have not experienced this issue ever since iOS 11 was released.

Sam Saffron
  • 128,308
  • 78
  • 326
  • 506
0

Maybe that's caused by automatic retries? Those posts mention that can happen under bad network conditions (like you said, subway):

https://medium.com/@fagnerbrack/the-day-a-bug-was-fixed-only-because-the-ceo-called-in-f653a34079eb

https://blogs.oracle.com/ravello/beware-http-requests-automatic-retries

fjsj
  • 10,995
  • 11
  • 41
  • 57
  • this issue only ever happens on Safari View Controller. It has started happening again recently which sucks. Never happens on Safari on iOS. – Sam Saffron Mar 05 '19 at 01:01