我听说 cookie 不如会话安全。

你一定是误解了什么。事实上，HTTP 会话通常是使用 cookie 实现的。

我在想，如果我能得到 &^*Y()UIH|>Guho976879，我仍然可以伪造 cookie，对吧？

当然您可以更改 cookie，但它会被服务器接受为有效吗？如果您实际查看文档，您会看到：

Cookie 不安全，很容易被客户修改。如果您需要设置 cookie，例如识别当前登录的用户，您需要签署您的 cookie 以防止伪造。Tornado 支持使用 set_secure_cookie 和 get_secure_cookie 方法签名的 cookie。...
签名 cookie 包含 cookie 的编码值以及时间戳和 HMAC 签名。如果 cookie 是旧的或签名不匹配，get_secure_cookie 将返回 None ，就像 cookie 未设置一样。

因此，如果您尝试操纵安全 cookie，框架会注意到该 cookie 并将其视为无效，即 cookie 从一开始就从未发送过。

我认为其他答案未能解决这里受到保护的主要攻击，这不是伪造cookie，而是篡改或检查它。

如果你向浏览器发送一个 cookie 说“current_user=tom”，用户可以给你发回一个替代的 cookie，说“current_user=dave”。如果您没有验证 cookie 的依据，您的应用程序将假定他们以“dave”身份登录。

这可以通过使用密钥对 cookie 进行签名来缓解 - 被篡改的 cookie 将没有正确的签名，因此会被拒绝。

但是，可能仍然存在一个问题：如果您要存储的部分状态是secret。例如，您可能希望将产品的成本价和加价存储在用户的购物篮中；显然，用户可以阅读的纯文本 cookie 在这里不合适。

这为您提供了两种解决方案：

• 对 cookie 的内容进行加密，使其在不知道私钥的情况下既不能读取也不能修改。
• 将实际数据存储在本地（例如，在磁盘或内存存储中）并仅在 cookie 中发送标识符。这通常称为“会话数据”。

会话相对容易实现，并且可以证明对这些特定攻击是安全的。但是，它们会给您的后端基础架构带来负担，因为您的 Web / 应用程序服务器需要能够写入和读取数据；例如，这在复杂的负载平衡设置中可能会很棘手。因此，直接在 cookie 中加密少量数据可能是一个明智的选择，因为现在需要在应用程序服务器之间共享的唯一数据是私钥。

请注意，这些都不能直接防止其他攻击，例如劫持，恶意用户只是从真正的会话中克隆 cookie。会话令牌也可能容易受到称为“会话固定”的相关攻击，攻击者在真正的用户连接之前选择标识符，从而可以为他们创建相同的 cookie；这对于加密的 cookie 是不可能的，但我敢肯定还有其他独特的攻击。

您发现的问题并没有真正描述您所指的（我认为）。他们所描述的区别在于用户的会话信息（例如，他们购物中的物品之类的东西）是否在服务器端并且只将唯一标识符（也称为会话 cookie）传递给客户端，或者是否存储整个东西在客户端。

所有 Web 应用程序都必须具有某种维护状态的机制。HTTP 默认是无状态的，因此服务器无法将一个请求对应到另一个请求。

大多数应用程序解决这个问题的方法是使用 cookie。使用 cookie 的安全挑战是众所周知的，如果正确实施，它们应该不会导致严重的安全问题。

执行此操作的其他选项通常是授权标头，因此使用 HTTP 摘要或 NTLM 身份验证。这在内部企业应用程序中更常见，或者使用 JavaScript 生成这些标头（您可以在一些现代单页应用程序中看到）。

无论如何，每个请求都需要从客户端传递到服务器的一些信息来识别用户。

对于伪造cookie，通常会话令牌具有很大程度的随机性，因此伪造cookie值是不切实际的。