iOS 偶尔发送旧 cookie答案

【问题标题】：iOS sporadically sends old cookiesiOS 偶尔发送旧 cookie
【发布时间】：2017-10-24 00:11:22
【问题描述】：

我有一个定期轮换身份验证令牌 cookie 值的应用程序。

每次服务器轮换令牌时，它不会将其标记为“良好”，直到它看到客户端拥有令牌（因为客户端将其包含在资源的请求标头中）。

我只有在 iOS (10.3) 上有一个非常特殊的情况，当网络条件发生变化时（例如：下地铁），它偶尔会发送一个非常旧的 cookie。当这种情况发生时，它会“忘记”最近的 cookie 值并“开始生活在过去”并发送旧值。

^{** 安全说明：IP 地址是在纽约市的 t-mobile 公开分配的，令牌早已从我们的数据库中删除}

这是一个已知问题吗？
对于 cookie 处理是否有任何在 iOS 上更强大的解决方法？ localstorage 并不理想，因为这些 cookie 只是 http。

澄清一下……这是流程：

客户端 (iOS Safari) 有一个名为 _t 的 cookie，其值为 old
客户端 (iOS Safari) 向服务器发出请求
我们发出Set-Cookie 并将_t cookie 设置为新值new（仅限http，安全cookie）
客户端使用新的 cookie 值 new 发出另一个请求。我们标记 cookie 值是好的并且客户端拥有它。
时间流逝
客户端使用_t cookie 发出请求，其值为old

【问题讨论】：

你在服务器上使用什么编程语言？
不关注，这有什么关系？
所以我可以给你一个特定于你的语言的答案。

标签： ios authentication cookies mobile-safari sfsafariviewcontroller

【解决方案1】：

也许这是由自动重试引起的？那些帖子提到了在糟糕的网络条件下可能发生的事情（就像你说的，地铁）：

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

【讨论】：

这个问题只发生在 Safari 视图控制器上。它最近又开始发生了，这很糟糕。在 iOS 上的 Safari 上永远不会发生。

【解决方案2】：

Safari 视图控制器在 iOS 11 及更高版本中不再与 Safari 共享 cookie，此更改解决了困扰 iOS 的 cookie 存储损坏问题。自 iOS 11 发布以来，我们从未遇到过此问题。

【讨论】：

【解决方案3】：

我的经历

我还通过随每个请求更改并存储在 cookie 中的 ID 使用身份验证。我可以确认这种行为，它仍然存在于 iOS 11（和 iOS 11.1 beta 3）中。在我的日志文件中，我可以看到有时旧 cookie 随机存储在 Safari 中。当一个独立的 web 应用关闭并重新打开时，会发生这种情况。

我的后备方法

我在 localStorage 上构建了一个备用方法。带有旧 cookie 的请求通常会将我数据库中的所有数据标记为无效。如果用户代理指向带有 iOS 的设备，我不会将数据标记为无效并让客户端再次尝试对其自身进行身份验证。

在客户端，我检查 localStorage 并使用这些数据创建新的 cookie。随后，进行新的认证。 localStorage 像每个请求的 cookie 一样被重写。如果再次验证失败，我将数据标记为无效。

【讨论】：

在 ios 11 中不再出现这种情况，问题已解决。

【解决方案4】：

SQLite 数据库，如果您愿意牺牲一点安全性的话。

【讨论】：

即使你切换到 PHP Session，you still need cookies to identify the session。然后我们只是把情况复杂化而不解决任何问题。
@Lucy：从技术上讲，是的。关键是，现在我们可能不需要关心上述问题，因为 cookie 现在只存储在整个浏览会话期间使用的 ID。
该问题是 cookie that at the very least would contain sessionID 的一般问题。所以原来的问题仍然存在。抱歉，您还没有减少问题空间。（也许只是 cookie 的大小，这里不相关）。而且，@shisui 的回答将 sessionID 称为可与 cookies 互换的术语，因为这在这里很重要。
@Lucy：我看到了问题并提供了另一种解决方案。

【解决方案5】：

这是我的理论：

在 cookie 生命周期中，每当用户身份验证状态发生变化（登录用户 -> 注销用户 || 注销用户 -> 登录用户），旧的 cookie 就会失效并被新的 cookie 替换。

但是为什么会发生在地铁而不是其他地方呢？
1. 如今，大多数地铁都提供免费的不安全 WiFi，以补充地下时糟糕的无线网络连接。
2. 10.3 有一些关于网络连接问题的报告，以及 this one 特别有趣，因为问题是 location dependent。
3. 我认为上述 (1) 和 (2) 的组合导致应用程序重新对服务器进行身份验证。也许您可以提取日志以检查是否确实如此？

可能的解决方法？

也许没有。
我们无法阻止 iPhone 用户进行 iOS 升级。大多数人已经这样做了。
此外，重新认证后不更改 cookie 的安全影响更严重。

根据截至 2017 年 5 月 31 日的评论更新：

鉴于评论中的详细信息。我们可以有更好的解释。

在cookie生命周期中，当用户注销时，server-side-invalidation应该发生。

工作流程：
1.当用户logout时，authenticated sessionID从浏览器中删除。
2. 但这还不够。服务器也需要invalidate 和sessionID。否则可能会产生安全影响。
3.在您的情况下，服务器可能没有失效。因此它仍然期待一个SessionID，它一直是deleted from the browser。

这只是一种可能的解释。确切地说，需要更详细的日志文件分析和更多的实验。

例如，在此期间，服务器日志是否发生了任何重新认证？
如果server-side-invalidation 已正确实施，我们能否在受控环境中进行测试？

【讨论】：

这里不涉及任何应用程序，这是一个使用iOS的标准网站，服务器使用Set-Cookie标头设置cookie。客户端发出第二个请求，并回显它具有 cookie。几小时后，它会运送一个较旧的 cookie。
已根据评论更新了答案。
请注意，这是 iOS 中的一个直接错误，现已解决。
我不确定这是否是相同的情况，但我注意到我们的 Web 应用程序用户的 ios 设备存在类似问题。我仍然需要进一步调查，但查看日志，似乎该用户的 Safari 浏览器正在随机重用具有陈旧信息的旧 cookie，因为请求显示了这种模式。用户代理显示了一个 11.4 的 ios 设备