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

Question

现在的授权方案如下所示：如果用户输入了正确的数据，服务器会生成一个唯一的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 一样被拦截，那么它还有什么意义呢？

Answer 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。这不能由浏览器自动完成，因此您可以免受 CSRF 攻击。