为了防止跨站点请求伪造的危险情况，需要对 HTTP 协议规范和浏览器行为进行哪些更改？
我不是在寻找有关如何修补我自己的网络应用程序的建议。有数百万个易受攻击的 Web 应用程序和表单。更改 HTTP 和/或浏览器会更容易。
如果您同意我的前提，请告诉我需要对 HTTP 和/或浏览器行为进行哪些更改。这不是寻找最佳单一答案的比赛，我想收集所有好的答案。
还请阅读下面我的“答案”中的要点并发表评论。
【问题讨论】：
HTTP 规范的作者 Roy Fielding 不同意您的观点，即 CSRF 是 HTTP 中的一个缺陷，需要在那里修复。正如他在reply in a thread named The HTTP Origin Header 中所写：
CSRF 不是 Web 的安全问题。精心设计的网络 服务应该能够接收任何主机指示的请求， 通过设计，在需要时进行适当的身份验证。如果浏览器 创建一个安全问题，因为它们允许脚本自动 将存储了安全凭证的请求直接发送给第三方 网站，无需任何用户干预/配置，那么显而易见 修复在浏览器中。
事实上，CSRF 攻击从一开始就可能使用纯 HTML。当今 JavaScript 和 CSS 等技术的引入只是引入了进一步的攻击向量和技术，使请求伪造更容易和更高效。
但这并没有改变这样一个事实，即来自客户端的合法且真实的请求不一定基于用户的意图。因为浏览器确实会一直自动发送请求（例如图像、样式表等）并同时发送任何身份验证凭据。
同样，CSRF 攻击发生在浏览器内部，因此唯一可能的解决方法是在浏览器内部修复它。
但由于这并非完全可能（见上文），因此应用程序有责任实施一种允许区分真实请求和伪造请求的方案。始终传播的 CSRF 令牌 就是这样一种技术。如果实施得当并能抵御其他攻击（同样，其中许多攻击只能通过现代技术的引入），它会很好地工作。
【讨论】：
我同意另外两个；这可以在浏览器端完成，但无法执行授权的跨站点请求。 无论如何，一个 CSRF 保护层可以很容易地添加到应用程序端（甚至可能在网络服务器端，以避免对预先存在的应用程序进行更改），使用如下方式：
【讨论】：
对表单提交位置执行同源策略。只允许将表单提交回它的来源地。
当然，这会破坏各种其他东西。
【讨论】：
如果您查看CSRF prevention cheat sheet，您会发现有一些方法可以通过依赖 HTTP 协议来防止 CSRF。一个很好的例子是检查嵌入式设备上常用的HTTP referer，因为它不需要额外的内存。
但是，这是一种较弱的保护形式。客户端的 HTTP 响应拆分之类的漏洞可用于影响referer 值，并且已经发生了这种情况。
【讨论】：
【讨论】：
已经可以做到了：
Referer标头这是一种较弱的保护形式。出于隐私目的，某些用户可能会禁用referer，这意味着他们将无法在您的网站上提交此类表单。这在代码中实现也很棘手。某些系统允许诸如http://example.com?q=example.org 之类的URL 通过example.org 的引荐来源网址检查。最后，您网站上的任何开放式重定向漏洞都可能允许攻击者通过开放式重定向发送他们的 CSRF 攻击，以获得正确的referer 标头。
Origin标头这是一个新的标题。不幸的是，支持和不支持它的浏览器之间会出现不一致的情况。 See this answer.
仅对于 AJAX 请求，添加不允许跨域的标头（例如 X-Requested-With）可以用作 CSRF 预防方法。旧浏览器不会跨域发送 XHR，而新浏览器将发送 CORS 预检，如果目标域明确不允许，则拒绝发出主请求。服务器端代码需要确保在收到请求时标头仍然存在。由于 HTML 表单无法添加自定义标题，因此此方法与它们不兼容。但是，这也意味着它可以防止攻击者在 CSRF 攻击中使用 HTML 表单。
Chrome allow third party cookies to be blocked 等浏览器。虽然解释说它会阻止第三方域设置 cookie，但它也会阻止为请求发送任何现有的 cookie。这将阻止“背景”CSRF 攻击。但是，那些打开整页或在弹出窗口中的会成功，但对用户来说更可见。
【讨论】：