4
将CSRF预防令牌放在cookie中为什么很常见？
我正在尝试了解CSRF的整个问题以及适当的预防方法。（我已阅读，理解并同意的资源：OWASP CSRF预防速查表，关于CSRF的问题。） 据我了解，CSRF周围的漏洞是由以下假设引入的：从Web服务器的角度来看，传入HTTP请求中的有效会话cookie反映了经过身份验证的用户的意愿。但是，源域的所有cookie都被浏览器神奇地附加到了请求上，因此，实际上服务器可以从请求中是否存在有效的会话cookie推断出，该请求来自具有经过身份验证的会话的浏览器。它无法进一步假设有关代码的任何信息在该浏览器中运行，或者是否确实反映了用户的意愿。防止这种情况的方法是在请求中包括其他身份验证信息（“ CSRF令牌”），该信息由浏览器的自动cookie处理以外的其他方式携带。松散地说，会话cookie对用户/浏览器进行身份验证，而CSRF令牌对在浏览器中运行的代码进行身份验证。 简而言之，如果您使用会话cookie来验证Web应用程序的用户，则还应该向每个响应中添加CSRF令牌，并在每个（变异）请求中要求匹配的CSRF令牌。然后，CSRF令牌从服务器到浏览器再返回到服务器，以向服务器证明发出请求的页面已被该服务器批准（由该服务器生成，甚至由该服务器生成）。 关于我的问题，这是关于该往返行程中用于该CSRF令牌的特定传输方法。 似乎很常见（例如在AngularJS，Django，Rails中），将CSRF令牌作为cookie从服务器发送到客户端（即在Set-Cookie标头中），然后让客户端中的Javascript将其从cookie中刮出并附加它作为单独的XSRF-TOKEN标头发送回服务器。 （另一种方法是Express推荐的方法，其中服务器生成的CSRF令牌通过服务器端模板扩展包含在响应主体中，并直接附加到将其提供回服务器的代码/标记中，例如作为隐藏的表单输入。该示例是一种更像Web 1.0的工作方式，但可以推广到使用更多JS的客户端。） 为什么使用Set-Cookie作为CSRF令牌的下游传输如此普遍/为什么这是个好主意？我想所有这些框架的作者都仔细考虑了他们的选择，并没有弄错这一点。但乍看之下，使用cookie来解决cookie的本质设计限制似乎很愚蠢。实际上，如果您使用cookie作为往返传输（服务器的Set-Cookie：下游标头告诉浏览器CSRF令牌，浏览器的cookie：上游标头将浏览器返回给服务器），则会重新引入此漏洞正在尝试修复。 我意识到上述框架并未在CSRF令牌的整个往返过程中使用cookie；他们在下游使用Set-Cookie，然后在上游使用其他内容（例如X-CSRF-Token标头），这确实消除了该漏洞。但是，即使使用Set-Cookie作为下游运输工具，也可能会产生误导和危险；浏览器现在将CSRF令牌附加到每个请求，包括真正的恶意XSRF请求；最好的情况是使请求大于所需的大小，最坏的情况是一些善意却被误导的服务器代码实际上可能会尝试使用它，这确实很糟糕。而且，由于CSRF令牌的实际预期接收者是客户端Javascript，这意味着该cookie不能仅通过http保护。