API服务应用程序上的CSRF TOKEN

Question

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

1. API是从api.domain.com提供的。

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

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

1. 从对某些端点（如/getCSRF的调用在前端应用程序初始化中获取CSRF令牌。

2. 在我的api.domain.com上启用CORS并仅允许来自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中的auth令牌）的另一种选择是双重发布 。 基本上，Web应用程序在登录响应中会设置一个cookie，该cookie具有足够长的加密随机值。 根据每个api请求，客户端读取cookie并将其添加为请求标头。 api服务器要做的就是比较csrf cookie值和csrf标头值是否相同（无服务器状态）。 显然，此csrf cookie不能为httpOnly，但这很好，如果您具有xss，则任何csrf保护都无济于事。 这是可行的，因为恶意.dom上的攻击者无法读取用户的yourdomain.dom cookie值，并且他也不能为yourdomain.dom设置新的cookie（根据相同的源策略）。