【问题标题】:CSRF TOKEN on api serving applicationapi服务应用程序上的CSRF TOKEN
【发布时间】:2018-09-13 14:55:47
【问题描述】:

目前,我的架构是这样的:

  1. API 由 api.domain.com 提供。

  2. 前端应用程序位于 frontend.domain.com。

我的问题是关于 CSRF 保护的,这是我的方法:

  1. 通过调用某个端点(如/getCSRF)在前端应用程序初始化时获取 CSRF 令牌。

  2. 在我的api.domain.com 上启用CORS 并只允许来自frontend.domain.com 的请求

注意:

我发现一个主要网站正在使用类似于我的第一种方法来获取 CSRF 令牌,但我认为这不是一个好方法。

谁能告诉我哪种方法更适合 CSRF 保护?

【问题讨论】:

  • 在响应之前调用端点然后用 CSRF 响应怎么样?
  • 我没明白你的意思

标签: node.js api csrf csrf-protection


【解决方案1】:

由于 web 应用程序和 api 位于不同的域上,因此 API 上的身份验证不能基于 cookie(嗯,可以,但这意味着需要单独登录 api,我不认为是这种情况)。

所以你以某种方式向 API 发送某种令牌,大概是作为请求标头,或者可能在请求正文中,这不太常见(希望不在 url 中,它仍然不会受到 csrf 的攻击,但由于其他原因,它肯定是一个弱点和反模式)。

在 csrf 中,攻击者让您的用户访问不同的域恶意.dom,并创建对 api.yourdomain.dom 的请求。但是,他们无法提供有效的身份验证令牌,因此您的 api 不会受到 csrf 的攻击。如果身份验证是基于 cookie 的,它可能会受到 csrf 的攻击,因为 cookie 是自动发送的。

如果您的 api 上的身份验证基于 cookie,那么您可以做的最简单的可能就是切换到基于令牌的身份验证(在请求标头中发送)。

编辑

在您的情况下防止 csrf 的另一个选项(cookie 中的身份验证令牌)是 double posting。基本上,在登录响应中,Web 应用程序设置了一个具有足够长的加密随机值的 cookie。在每次 api 请求时,客户端都会读取 cookie 并将其添加为请求标头。 api服务器所要做的就是比较csrf cookie值和csrf header值是否相同(无服务器状态)。很明显,这个csrf cookie不能是httpOnly,不过没关系,如果你有xss,反正任何csrf保护都没用。这是可行的,因为恶意.dom 上的攻击者无法读取 yourdomain.dom 的用户 cookie 值,并且他也无法为 yourdomain.dom 设置新 cookie(根据同源策略)。

【讨论】:

  • 由于它是一个 Web 应用程序,我只使用 HTTP 在 cookie 中传递令牌,因此如果我的应用程序易受 XSS 攻击,我的身份验证是安全的,但我仍然容易受到 CSRF 攻击
  • @iambatman 好的,所以您将 auth cookie 设置为顶级域。你是对的,拥有一个 httpOnly cookie 可以防止通过 XSS 获取它,但这值得吗? (理论问题,只有你自己知道。)我编辑了我的答案,并针对你的情况提出了另一个建议。
  • 感谢您的详细解释,如果我切换到基于令牌的身份验证,每个请求都会在请求标头中附加令牌,因为我需要将其存储在 cookie 中(Httponly false),但是如果我处于 XSS 漏洞之下,我的令牌就会暴露??
  • @iambatman 是的。然后,您的身份验证令牌需要可供 Javascript 访问。您可以做的最安全的做法是将身份验证令牌存储在 httpOnly cookie 中,并使用一些无状态保护,例如针对 csrf 的上述双重发布。最方便的可能是基于令牌的身份验证,在这种情况下,csrf 不是什么大问题,但 xss 可以获取身份验证 cookie。请注意,即使身份验证令牌在 httpOnly cookie 中,xss 仍然非常糟糕。所以,你的选择。 :)
  • @iambatman 假设您有 api1.domain1.com 和 api2.domain2.com,并且身份验证在 www.domain1.com 上。那么 cookie 仅对 domain1.com 有效,您无法将令牌发送到 api2.domain2.com。如果您不想这样做,那很好,但有时人们需要这样做。 :)
猜你喜欢
  • 2017-03-18
  • 2017-12-18
  • 2017-05-21
  • 2022-01-08
  • 1970-01-01
  • 2021-10-17
  • 2018-10-14
  • 2021-12-20
  • 2015-10-17
相关资源
最近更新 更多