...如果 XMLHttpRequest 应该发送 cookie，则必须设置 withcredentials-flag。即使这样，目标服务器也必须实现 CORS 标头才能使请求成功。...哪些浏览器已经实施了这些反措施，以及它们是否足以作为防御，或者我们是否仍需要在我们的应用程序中实施 CSRF 缓解措施。

XHR 的 CORS 不是新的缓解措施，甚至根本不是针对以前有效攻击的缓解措施。什么XMLHttpRequest时候设计的，根本不可能有跨域请求。并且只有在引入 CORS 后，此限制才被更改并替换为由 CORS 策略控制的跨域请求。因此，所有没有实现 CORS 的旧浏览器一开始就不会通过 XHR 受到 CSRF 的影响。

尽管如此，CSRF 仍然是一个问题，并且仍然可以像过去一样使用。XHR 根本不需要作为 CSRF 攻击的载体，而且它在过去无论如何都不起作用。取而代之的是跨站点图像，可以使用跨站点表单提交或类似方法，它们仍然会自动跨站点发送必要的凭据和 cookie。cookie的新samesite属性可用于防止这种情况发生，但必须由应用程序显式设置，并且并非所有浏览器都支持它。

因此，今天仍然需要适当的 CSRF 保护。

如果没有正确实施 CSRF 保护会发生什么，例如最近的新闻，例如黑客利用零日漏洞对 800,000 台 DrayTek 路由器发起大规模网络攻击。

默认情况下，跨站点请求中不发送身份验证所需的 Cookie 和标头。

这是不正确的。如果用户点击一个链接或张贴在一个形式evil.com来example.com，cookies将被包括在内。用户甚至不必单击链接或提交按钮，它可以通过脚本自动完成。

例如，如果 XMLHttpRequest 应该发送 cookie，则必须设置 withcredentials-flag。即使这样，目标服务器也必须实现 CORS 标头才能使请求成功。

当然可以。但是，当您可以使用老式形式时，为什么攻击者需要 XHR？

所以我现在想知道，哪些浏览器已经实施了这些反措施，它们是否足以作为防御，或者我们是否仍然需要在我们的应用程序中实施 CSRF 缓解措施。

浏览器没有实现任何自动反制措施，所以你仍然需要这样做。无论我们使用多么现代的浏览器，易受攻击的网站都将继续受到攻击。

不过，在一方面你是对的。现代 API:s 通常被设计成默认为它们提供至少一些 CSRF 保护的方式。例如，如果您使用授权标头而不是 cookie 进行身份验证，或者您只接受带有 JSON 正文的 POST 请求，就会发生这种情况。

如果我必须对此事发表评论，那么这将最好地反映在这篇文章中所写的内容中。

https://medium.com/@jrozner/wiping-out-csrf-ded97ae7e83f

CSRF 在类似于 IPv4 的情况下仍然是相关的——我们暂时还不能逐步淘汰它所专有的遗留系统，最终会出现它的排列。

一如既往; 记得给你的系统打补丁