问会话标识应该在cookie中加密吗？

EN

根据您告诉我们的，您的设置可能是安全的，也可能是不安全的。你需要提供更多的细节让我们知道。

例如，根据您告诉我们的内容，您基本上是在向用户发出两个不同的承载令牌，其中一个令牌存储在httpOnly cookie中，另一个令牌存储在LocalStorage中，其中一个令牌被存储在会话12345中，并且只有在两个令牌都存在且有效且匹配时才允许访问。

但是，您的描述并没有明确说明LocalStorage令牌是否也将作为cookie令牌有效，反之亦然。如果可能，捕获其中一个令牌的攻击者只需在同一个Ajax请求中提交两次相同捕获的令牌，一次在cookie中，一次在请求参数中，因此看起来是有效的。

此外，仅仅检查请求中的两个令牌是否相同是不够的，因为攻击者可能能够为同一会话捕获两个不同的有效LocalStorage令牌。相反，要防止这种攻击，您需要做的是在构成令牌的签名数据中包含某种令牌类型标识符(例如，type: "cookie"和type: "param")，并验证每个令牌的类型是否与向服务器显示令牌的方式相匹配。

或者，您也可以为cookie令牌和参数令牌使用两个不同的签名密钥；这样，将令牌从LocalStorage复制到cookie中(反之亦然)将自动使签名无效。

这就是说，只要您以某种方式确保每种类型的令牌只有在通过适当的通道显示时才有效，那么您的设置至少与使用单个令牌一样安全。它还应该防止某些类型的附加攻击，例如CSRF攻击(允许攻击者使用合法用户的cookie发出恶意请求)和某些类型的JS注入攻击(这些攻击可能会危及用户的LocalStorage，但不会危及用户的cookie)。

但是，我们不能真正判断这些攻击是否是与您的应用程序相关的威胁，以及是否存在其他您的计划不足以防范的攻击。特别是，虽然您的方案应该对只危及LocalStorage的攻击提供足够的保护，但值得注意的是，大多数可以执行的攻击也允许攻击者做其他事情，例如在用户的浏览器中发出自己的Ajax请求(这会妨碍您的方案)。

也就是说，至少您的方案(如果实现正确)提供CSRF保护，这是一件有用的事情。它是否提供了比这更多的东西则是另一回事。

(在任何情况下，只要攻击者知道会话ID就不能进行任何恶意操作，通常就不需要加密会话ID或包含会话ID的任何令牌。如果可以，那么拥有"12345“这样的会话ID也是个坏主意，因为攻击者很容易尝试从0到999999的所有会话ID。)