关于api服务申请的CSRF TOKEN

Question

目前，我的架构是这样的：

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

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

我的问题是关于CSRF保护，以下是我的方法：

1. 通过调用/getCSRF之类的某个端点，在前端应用程序初始化时获取CSRF令牌。

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

的请求

注意：

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

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

Answer 1

由于Web应用程序和api位于不同的域上，API上的身份验证不能基于cookie（嗯，它可以，但这意味着单独登录api，我不认为是这种情况） ）。

所以你要以某种方式向API发送某种类型的令牌，可能是作为请求头，或者可能在请求体中，这不常见（并且希望不在url中，这仍然不会受到csrf的攻击） ，但由于其他原因，这绝对是一个弱点和反模式。）

在csrf中，攻击者会让您的用户访问另一个域恶意。并向api.yourdomain.dom创建请求。但是，他们无法提供有效的身份验证令牌，因此您的api不容易受到csrf的攻击。如果身份验证是基于cookie的，那么它很容易受到csrf的攻击，因为cookie是自动发送的。

如果你的api 上的身份验证是基于cookie的，那么最简单的你可以做的是切换到基于令牌的身份验证（在请求头中发送）。

修改

在您的情况下防止csrf的另一个选项（cookie中的身份验证令牌）是double posting。基本上在登录响应中，Web应用程序使用足够长的加密随机值设置cookie。在每个api请求时，客户端读取cookie并将其添加为请求头。所有api服务器必须做的是比较csrf cookie值和csrf头值是否相同（没有服务器状态）。显然，这个csrf cookie不能是httpOnly，但是没关系，如果你有xss，任何csrf保护都无用了。这是有效的，因为针对恶意.dom的攻击者无法读取yourdomain.dom的用户cookie值，并且他也无法为yourdomain.dom设置新的cookie（根据相同的原始策略）。