首页 > 解决方案 > 如果使用 HTTPOnly cookie,是否需要 CSRF 中间件?它应该是基于会话的吗?

问题描述

现在授权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 一样被拦截,那它还有什么意义呢?

标签: securitycookiesxsscsrf

解决方案


让我们首先说明跨站点脚本 (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 攻击。


推荐阅读