如果使用 HTTPOnly cookie，是否需要 CSRF 中间件？它应该是基于会话的吗？答案

【问题标题】：Is CSRF middleware needed if HTTPOnly cookie is used? And should it be session-based?如果使用 HTTPOnly cookie，是否需要 CSRF 中间件？它应该是基于会话的吗？
【发布时间】：2021-11-13 04:58:58
【问题描述】：

现在授权 sheme 如下所示：如果用户输入了正确的数据，服务器会生成一个唯一的 sessionKey，用 FK 将它插入到这个用户的会话表中。为了响应 JSON 请求，我发送了这个 sessionKey。 Web 客户端将此密钥设置在 cookie 中。

但问题是，如果web客户端存储了这个cookie，JS就可以访问它们，而且不安全。另一种方法是设置 HTTP-Only cookie。但不清楚这种情况下是否需要使用 CSRF 中间件。 HTTPOnly 属性是否解决了 XSS/CSRF 攻击的问题？如果它没有决定并且你需要一个 CSRF 中间件，那么 csrf cookie 必须是一个会话 cookie。

问题是我的框架的所有 csrf 中间件都不允许使用会话 csrf cookie。或者，编写我自己的中间件。我是否正确理解 csrf 中间件将我提供给客户端的令牌存储在 RAM 中并在每个请求上进行验证？但是如果可以像授权cookie一样被拦截，那么这个token还有什么意义呢？

【问题讨论】：

标签： security cookies xss csrf

【解决方案1】：

让我们首先说明跨站点脚本 (XSS) 和跨站点请求伪造 (CSRF) 是两种不同的动物。

XSS 是关于将恶意代码嵌入站点以使其在客户端计算机上执行。没有 HTTPOnly 标志可以缓解这种情况。
CSRF 是关于在某些第三方站点上嵌入恶意代码并向您发送到第三方站点的链接。恶意代码可以尝试触发 GET/POST 请求（可以绕过浏览器的同源策略）并在用户登录的站点上执行一些不需要的操作。举个例子更容易理解：
1. 您已通过https://example.com 登录您的站点。您已通过 cookie 进行身份验证。
2. 有人向您发送了指向https://malicious.net 的链接。您在单独的浏览器选项卡中打开该链接。
3. 正在执行恶意代码并向https://example.com/deleteAccount=1 发起请求。将附加 Cookie，请求将被验证并执行。

答案是否定的——HTTPOnly 标志不会缓解任何这种情况。但是让我们集中精力解决 CSRF 问题。你有什么选择？

其实你有很多：https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

IMO 最简单的方法可能是不通过 cookie 传递 sessionKey，而是通过 Authorization 标头传递。这不能由浏览器自动完成，因此您可以免受 CSRF 攻击。

【讨论】：