CSRF 令牌 - 我们是否需要在大多数情况下使用它们？

Question

所以我基本上进行了一次史诗般的航行，以弄清楚如何实现 CSRF 令牌。 20 年后——现在我觉得我只是浪费了我的生命。哈哈

所以基本上在制作恶意测试客户端并重新阅读之后，如果：

1) 您不允许使用过时的浏览器（它们不强制执行 CORS）

2) 您通过在资源上设置“Access-Control-Allow-Origin”来不允许 CORS。

3) 您使用 JSON API（所有请求-响应都在发送 JSON）。

4) 你负责 XSS（他们可以注入从同一来源运行的代码）。

只要你处理好 XSS（Reactjs！Holla）——以上所有（减去我猜的旧浏览器部分）基本上是常见的做法和开箱即用的设置——所以看起来像担心 csrf 令牌是浪费时间。

问题：

因此，为了避免将笔记本电脑扔到行驶中的汽车下 - 如果我已经遵守上述 4 种预防策略，我是否有任何理由添加 CSRF 令牌？

---

Just Fun Info - 想分享一个有趣的发现我的测试：

我在测试中发现的唯一东西是“GET”请求和一个图像标签

例如

<img src="http://localhost:8080/posts" onload={this.doTheHackerDance} />

上面将传递您的 cookie，因此可以成功访问端点，但显然因为它期待一个图像 - 它什么也不返回 - 所以你不会做黑客舞蹈。 :)

BUUUUT 如果该端点除了返回数据之外还做其他事情，比如一个好的小“GET”请求（比如更新数据）——黑客仍然可以点击“dab！” on ya（对不起，病毒式舞蹈动作参考）。

---

Answer 1

tl;dr - 要求 JSON 请求可以缓解 CSRF，只要在服务器端使用 content-type 标头进行检查。

在大多数情况下我们需要使用它们吗？

在大多数其他情况下，是的，尽管有workarounds for AJAX requests。

---

1. 您不允许使用过时的浏览器（它们不强制执行 CORS）

1. 您不允许通过在资源上设置“Access-Control-Allow-Origin”来允许 CORS。

利用 CSRF 漏洞不需要 CORS。

如果 Bob 为您的站点存储了 cookie，CORS 允许您的站点允许其他站点使用 Bob 的浏览器和 cookie 从它读取。

• CORS 削弱了 Same Origin Policy - 它不会增加额外的安全性。
• Same Origin Policy（一般情况下 - 请参阅下面的警告）不会阻止向服务器发出请求，它只是停止读取响应。
• Same Origin Policy 不会以任何方式限制非 JavaScript 请求（例如，<form> 或 <img> HTML 指令发出的 POST）。
• 不支持 CORS 的浏览器也不支持 AJAX 跨域请求。

因此，尽管出于其他原因（其他站点无法访问 Bob 的会话），不从您的站点输出 CORS 标头是好的，但不足以阻止 CSRF。

1. 您使用 JSON API（所有请求-响应都在发送 JSON）。

实际上，如果您将 content-type 设置为 application/json 并验证此服务器端，您 正在缓解 CSRF（这是上面提到的警告） .

Cross-origin AJAX requests can only use the following content-types:

• application/x-www-form-urlencoded
• 多部分/表单数据
• 文本/纯文本

这些请求是唯一可以使用 HTML（表单标签或其他）发出的请求。

4. 您负责 XSS（他们可以注入将从相同运行的代码 原产地）。

当然。 XSS 几乎总是比 CSRF 更严重的漏洞。因此，如果您容易受到 XSS 的攻击，您还有其他问题。

BUUUUT 如果该端点除了返回数据之外还执行其他操作 好小的“GET”请求（比如更新数据）——黑客仍然可以攻击 “轻拍！” on ya（对不起，病毒式舞蹈动作参考）。

这就是GET is designated as a safe method 的原因。它不应更改您的应用程序状态。要么按照标准使用 POST（推荐），要么使用 CSRF 令牌保护这些 GET。

Answer 2

请遵循 OWASP 的 guidelines：“一般建议：同步器令牌模式”。他们知道自己在做什么。

如果您使用的是框架，CSRF 对策并不难。例如，使用 Spring Security 非常简单。如果您不使用安全框架，那么您将大费周章。把事情简单化。使用一种通用方法来防止 CSRF，您可以在多种类型的项目中使用该方法

1. CSRF 与 CORS 正交。即使您在服务器上禁止 CORS 并且您的用户使用最新的 Chrome，您也很容易受到攻击。您可以使用 HTML 表单和一些 JavaScript 进行 CSRF。
2. CSRF 与 XSS 正交。即使您的服务器上没有 XSS 漏洞并且您的用户使用最新的 Chrome，您也很容易受到攻击
3. CSRF 可能发生在 JSON API 上。依靠 Adob​​e 确保 Flash 的安全，后果自负

新的 SAMESITE cookie 属性会有所帮助，但在那之前您需要反 CSRF 令牌。

继续阅读