javascript - 您如何保护浏览器使用的 RESTful API 免受 CSRF 攻击？

Question

我正在为一组网站设计 API。这些站点非常相似(有点像 StackOverflow、SuperUser 和 ServerFault)，它们有一个共享的后端是有意义的。因此，我们决定尝试使用一个很好的 REST API 作为后端，以及一堆使用所述 API 的非常相似但不同的前端。前端最好是全静态的，但如果事实证明这是不可能的，那也不是硬性要求。

我现在正在设计该 API，我担心安全隐患，尤其是 CSRF。根据我对 CSRF 攻击的基本理解，它们由两个重要组成部分组成:

1. 能够命名资源和请求正文。

2. 诱使用户/浏览器使用环境身份验证(如 session )向看起来已通过身份验证的资源发出请求。

许多修复 CSRF 攻击的经典方法都是基于 session 的。由于我的 REST API 并不真正执行 session ，这既可以防止很多向量，也可以防止几乎所有修复它们的方法。例如，双重提交没有意义，因为没有什么可以双重提交。

我最初的方法涉及攻击 CSRF 攻击的第 2 部分。如果我对所有请求进行身份验证(比如使用 HTTP Basic Auth)，并且浏览器不保存这些凭据(例如，一些 JS 发出了请求)，只有拥有凭据的 JS 才能发出请求，我们就完成了.明显的缺点是应用程序需要知道用户的凭据。另一个不太明显的缺点是，如果我想在 API 端安全地存储凭据，那么验证密码应该花费固定的、重要的时间。如果安全地验证密码需要 100 毫秒，那么每个其他请求将至少需要 100 毫秒 + eps，并且需要一些该死的聪明的客户端技巧才能让它感觉不慢。我也许能够缓存它(因为凭据总是相同的)，如果我非常小心，我可能会在不引入计时漏洞的情况下设法做到这一点，但这听起来像是马蜂窝。

OAuth 2.0 似乎有点过头了，但我想这毕竟是最好的解决方案，以免我最终实现不当。我想我现在可以做 HTTP Basic Auth 的事情，当我们有第三方应用程序开发人员时转向 OAuth。

与 OAuth 的阻抗不匹配。基本上，OAuth 确实想帮助应用程序访问另一个应用程序上的内容。我希望用户在这样的帐户存在之前就在其中一个前端注册。

我还考虑过通过使 URL 随机化来攻击第 1 点——即将标记添加到查询字符串。这肯定会起作用，并且它非常接近表单中传统随机标记的工作方式，并且考虑到 HATEOAS，它甚至应该是相当 RESTful 的，尽管这提出了两个问题:1) 你从哪里开始？是否有一个强制性的 API 起点，您可以在其中使用 HTTP Basic Auth 登录？ 2) 如果应用开发者不能预先预测一个 URL，那该死的 HATEOAS 会让他们高兴多少？

我看过How to prevent CSRF in a RESTful application? ，但我不同意随机 URI 必然是非 RESTful 的前提。此外，该问题并没有真正令人满意的答案，也没有提到 OAuth。此外， session 双重提交解决方案无效，正如我上面提到的(静态前端的域与 API 端点的域不同)。

我意识到我在这里的根本目的是尝试允许来自一个域的跨站点请求并禁止来自另一个域的跨站点请求，这并不容易。当然必须有一些合理的解决方案？

Answer 1

根据定义，CSRF token 是“每个用户状态”，因此不是 RESTful。出于安全目的，大多数 API 打破了“每个用户状态”的要求，并要求将 CSRF token 作为 HTTP header 参数传递。

preventing CSRF还有其他方式.检查引荐来源网址不如 CSRF token 强大，但它是 RESTful 并且非常不太可能被破坏。请记住，缺少引用者应被视为请求失败。

XSS 可用于绕过基于 token 的 CSRF 预防和基于引用的 CSRF 预防。