SPA中刷新令牌Cookie的CSRF保护

Question

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

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

角$http引用解释了我们应该如何对抗CSRF的默认机制:服务器必须设置一个名为XSRF-TOKEN的cookie。此cookie必须具有Javascript可读性，以便我们可以在请求中设置X-XSRF-TOKEN header。这种机制是否足以保护refreh令牌场景？

1. 第一次启动应用程序。没有访问令牌或cookie可用，我们必须用用户名和密码登录。api/login为我们提供了一个访问令牌，我们将其保存在内存中，并设置两个cookie。HttpOnly重发令牌cookie和JS可读的XSRF-TOKEN cookie。
2. 访问令牌过期。对api/token的调用验证XSRF-TOKEN并使用令牌cookie返回一个新的访问令牌；设置一个新的刷新cookie
3. 从AppCache重新启动应用程序。内存中没有访问令牌，只有cookies可用。用api/token..。
4. 坏人想偷我们的饼干。准备好的页面使用cookies向api/token发出请求，但没有X-XSRF-TOKEN HTTP头。

有严重的安全问题吗？

Answer 1

据我所知，最好的方法是在服务器内部和之后使用CSFR令牌呈现index.html时，您可以作为标准的AngularJS SPA进行操作。因此，通过后端服务/框架生成的CSFR令牌丰富了index.html。SpringSecurity为模板注入令牌提供了很好的支持。

在此之后，您可以使用javascript从模板中获取令牌，并使用httpInterceptor's、request钩子(或cookie)将其设置为头中的所有request请求。(或cookie)？我不清楚地记得正确的方法是什么，但我确信您在上面提到的文章中已经描述了它。