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

Question

现在授权sheme是这样的： 如果用户输入了正确的数据，服务器会生成一个唯一的 sessionKey，并将其插入到会话 table 中，并为该用户设置 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

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

• XSS 是指将恶意代码嵌入到站点中以使其在客户端计算机上执行。没有 HTTPOnly 标志可以缓解这种情况。
• CSRF 是关于在某些第三方站点上嵌入恶意代码并将您 link 发送到第三方站点。恶意代码可以尝试触发 GET/POST 请求（可以绕过浏览器的同源策略）并在用户登录的站点上执行一些不需要的操作。通过示例更容易理解这一点：
  1. 您已于 https://example.com 登录您的站点。您已通过 cookie 进行身份验证。
  2. 有人向您发送 link 到 https://malicious.net。您在单独的浏览器选项卡中打开 link。
  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，而是通过授权 header。这不能由浏览器自动完成，因此您可以免受 CSRF 攻击。