SPA中刷新令牌Cookie的CSRF保护

CSRF Protection for Refresh Token Cookie in SPA

本文关键字：CSRF 保护 Cookie 令牌 刷新 SPA      更新时间：2023-09-26

我在AngularJS SPA中使用资源所有者密码凭证OAuth 2.0流。有几篇文章(这里，这里…)和这个问题的答案解释了我们不应该在(web)客户端(LocalStorage)上存储刷新令牌，而是将它们加密存储在HttpOnly Cookie中，并使用代理API实现刷新令牌的解密，将其转发给安全令牌服务。

大多数文章都暗示我们应该通过使用一种常见的保护机制来关心CSRF。我想知道单页应用程序的最佳解决方案是什么。

Angular的$http引用解释了我们应该如何对抗CSRF的默认机制:服务器必须设置一个名为XSRF-TOKEN的cookie。这个cookie必须是Javascript可读的，这样我们就可以在我们的请求中设置X-XSRF-TOKEN HTTP头。这种机制是否足以保护刷新令牌场景?

  1. 首次启动应用程序。没有访问令牌和cookie可用，我们必须登录用户名和密码。api/login为我们提供了一个访问令牌，我们将其保存在内存中并设置了两个cookie。HttpOnly刷新令牌cookie，以及JS可读的XSRF-TOKEN cookie

  2. 访问令牌过期。调用api/token验证XSRF-TOKEN，并使用令牌cookie返回一个新的访问令牌;设置一个新的刷新cookie

  3. 从AppCache重启应用程序。内存中没有访问令牌，但可用cookie。使用api/token…

  4. 坏人想偷我们的新饼干。一个准备好的页面用我们的cookie请求api/token，但是没有X-XSRF-TOKEN HTTP头。

有严重的安全问题吗?

据我所知，最好的方法是当服务器呈现index.html时，里面有CSFR令牌，然后作为标准AngularJS SPA运行。因此，index.html随后使用后端服务/框架生成的CSFR令牌进行了充实。SpringSecurity为向模板注入令牌提供了很好的支持。

之后，您可以使用javascript从模板中获得令牌，并通过使用httpInterceptor, request钩子将其设置为头中的所有$http请求。(或cookie) ?我不太记得正确的方法是什么，但我相信你上面提到的文章中有描述。

相关文章：