在 cookie 中存储会话数据答案

【问题标题】：Storing session data in cookies在 cookie 中存储会话数据
【发布时间】：2013-08-30 07:39:05
【问题描述】：

最近我偶然发现了一些建议使用 cookie 来存储会话数据的文章。我喜欢这个想法，并通过添加一个运行良好的 CookieStorage 类来扩展我的会话存储（请注意，每个用户我使用唯一的哈希密钥来签名和加密数据）但是，还有很多其他文章建议不要将敏感数据存储在 cookie 中，即使您对值进行了加密和签名。

就个人而言，我没有理由不这样做，尤其是在为每个用户使用不同的密钥加密和签名值时。数据被泄露的风险与正常会话相同，不是吗？更不用说如果你使用 SSL，那么劫持的风险就会被消除。

我认为这种方法的好处是，如果会话数据不大，服务器上用于打开/读取/写入会话数据的 IO 操作更少，无论存储是基于文件、数据库还是基于内存

感谢您对此事的反馈

谢谢

【问题讨论】：

您在减少 I/O 方面看到的好处很可能一开始并没有那么大（尤其是 deceze 已经说过，当您使用 memcached 或其他东西时）——但您购买的是更多数据发送每个 HTTP 请求，这将使用户浏览您的网站的速度变慢。（您可以将 cookie 限制到某个路径，可以，但如果您想在项目的每个页面上使用它们，那么该路径很可能只是 /）
确实响应会更大，但这也取决于会话数据。如果你的会话很小，你不会有问题。另一方面，如果您有一个非常繁忙的站点，只需使用 cookie 作为会话的存储空间，就可以节省大量 I/O。
不仅响应会更大，请求也会更大。如果没有额外的措施，cookies 也会发送到静态资源请求中，比如 JS、CSS、图像，即使它们对会话数据不是最不感兴趣的（是的，可以通过将它们放在另一个子域中来克服）。对于您的“非常繁忙”的站点，上述用于存储会话数据的 memcache 或类似内容将减少/消除物理 I/O 操作。而 cookie 中的加密数据将意味着更多的 CPU 消耗用于解密。
而且因为数据要被加密，它永远不会被客户端使用。所以在客户端和服务器之间来回发送它真的没有多大意义。结论：除了在非常特殊的情况下，恕我直言，这仍然不是一个好主意。
当然，memcached/redis 是很好的选择，但仍然是 I/O。假设您还使用上述内容进行缓存并且页面命中缓存假设 5 次以获取数据，并且您需要为每个请求执行 2 次操作（仅用于会话），假设一个非常高流量的站点，它可能值得 CPU 周期。至于被加密的数据和不可用的客户端，我没有看到不利的一面。您是否使用所有 cookie 客户端？我很少这样做

标签： php session cookies

【解决方案1】：

如果您使用的是纯 cookie 存储，完全没有服务器端组件，则用户可以控制数据。唯一阻止他的是你的加密/签名方法；但这可能会受到攻击。如果您没有使用特定于用户会话的加密/签名密钥（即您没有使用服务器端会话），那么您几乎受限于静态密钥。有人可以离线攻击它，试图暴力破解它。一旦他们这样做了，他们就可以欺骗整个会话。

如果您正在使用存储在服务器端会话中的更安全的一次性随机机密...您已经将数据存储在服务器端会话中！为什么不保持简单并将所有内容存储在那里？它还可以减少每次请求来回传输所有 cookie 所需的带宽需求。

如果您这样做主要是为了节省服务器上的 I/O 操作：请使用更高效的会话存储，例如基于内存缓存的存储。

【讨论】：

更不用说重放攻击了。攻击者不需要知道加密 cookie 的含义，而只需知道该字符串并将其发回即可。如果服务器无法知道这是否是活动会话，则 cookie 仍然有效。
@deceze，感谢您的意见。所有有效积分。问题是，成功地暴力破解强加密有多大可能。然后，这同样适用于普通会话 ID。有人可能会尝试猜测有效的会话 ID 标识符并劫持会话。
@Sven, cookie有用户上次活动时间的信息。在 20 分钟不活动后，cookie 不再有效。所以重放攻击不是问题，没有欺骗性的 cookie
@Thomas 这取决于加密的强度以及攻击者的决心。如果您对每个人都使用一个静态机密，那将是非常危险的。如果您使用仅在一段时间内有效的随机生成的密钥，则风险会大大降低。与会话 ID 的有限有效性相同的原理。
与破解使用强密码术加密的数据相比，攻击者更有可能侵入服务器。在 cookie 中存储会话数据的最大限制是 cookie 的大小。

【解决方案2】：

虽然现在会话 id 仅通过 cookie 传输，但最初还有其他方式，仍然受支持并且可以使用。
有时服务器需要知道或更改会话信息。
@CBroe 关于 cookie 大小的点。

【讨论】：

2 是什么意思？服务器将能够很好地更改数据。这里的想法是使用 cookie 作为持久性介质，而不是文件系统或 db 或 memcached 或 redis 或任何东西