node.js - 为什么 CSRF token 要加密？

Question

我正在努力将安全的 CSRF token 实现到使用 express-sessions 的 Nodejs 后端和 React 前端应用程序中。我创建了this module在 Redis 中生成、验证和存储 CSRF token ，并包括一些额外的安全性，例如每个 token 的单独 key (用于 BREACH 安全)、每个功能 token 以及对同一功能的多个选项卡的支持(因此是 token ID 和 key )。

我读到 CSRF token 是加密的，只有服务器知道 key ，因此当浏览器将 token 发送到服务器时，服务器可以通过只有服务器知道的 key 进行验证。 我的问题是为什么它们被加密？

据我了解，如果攻击者以某种方式设法窃取加密 token ，那么加密就没用了，因为当他们使用 token 提交请求时，服务器会验证它，因为它本质上是相同的加密 token 。如果是这种情况，那么将 token 也存储在服务器上并检查客户端提交的 token 是否匹配不是会更高效吗？ (当然在比较中考虑了定时攻击)

谢谢

Answer 1

CSRF token 通常不加密。在普通 Web 应用程序中使用同步器 token 模式的教科书实现中，CSRF token 只是一个足够大的随机值，存储在服务器上，并在表单生成时提供给客户端。然后，客户端可以将其与表单一起发送回来，证明它发送的表单实际上是由服务器生成的，而不是由其他人生成的。 (即使在双重发布等其他模式的情况下，作为 header 字段和 cookie 之类发送的 token 在基本情况下也只是随机 token 。)

但是，有两点需要注意。

同步器 token 模式(经典的 CSRF token )需要服务器查找。无论如何，如果存在用户 session ，这并不是什么大问题，但情况并非总是如此，某些应用程序被设计为无状态的。在这种情况下，您不能只拥有一个随机 token ，因为如果不检查服务器端状态，您就无法决定它是否有效。

另一件事需要注意的是，如果 token 包含有关客户端的一些信息，您实际上可以进一步提高安全性。例如，如果 csrf token 以某种方式与客户端相关联(例如，如果它在更幼稚的实现中与当前客户端 IP 地址相关联)，那么以某种方式窃取 csrf token 就没那么有用。同样，您可以在服务器端存储这些附加信息，但这又是一些应用程序希望避免的状态，以使负载平衡等事情变得更容易。

因此，这归结为无状态 CSRF token ，您可以按原样检查这些 token ，而无需在后端进行状态(数据库)查找。

您可以做的(以及某些框架为您做的)是创建一个结构化 token ，其中嵌入一些数据，并使用只有服务器知道的 key 对其进行加密。然后，服务器将其作为 CSRF token 发送，并期望在状态更改请求时接收它。当它收到返回的 token 时，服务器不需要查找数据库，它只需解密 token 并查看它是否是服务器创建的有效 token 即可。

请注意，纯粹出于此目的，您实际上不需要加密，更合适的加密原语是消息身份验证代码，因为您只关心 token 的真实性，即。服务器本身创建了它，而不是其他人。然而，一些框架包含在 token 中的数据多次受到加密(以及通过适当的经过验证的加密算法的隐式消息验证)的进一步保护。但在一个非常基本的实现中，您实际上可以仅包含时间戳和用户 ID 以及 hmac 作为无状态 CSRF token (但包含更多信息，甚至可能有关生成的表单字段会进一步提高安全性)。

所以简而言之，未加密的随机 token 被认为足以满足 CSRF 的要求，并且在双重发布的情况下，它们也可以是无状态的(由于同源策略，攻击者无法将相同的随机 token 发布到不同的来源，因为cookie 并作为 header )。但是，如果需要的话，加密的、信息更丰富的 token 可以提供更高的安全性，甚至还可能在一定程度上减轻被盗的 CSRF token 威胁。