为了防止跨站点请求伪造的危险情况，需要对HTTP协议规范和浏览器行为进行哪些更改？
我不是在寻找如何修补我自己的网络应用程序的建议。有数百万个易受攻击的网络应用和表单。更改HTTP和/或浏览器会更容易。
如果您同意我的前提，请告诉我需要对HTTP和/或浏览器行为进行哪些更改。这不是寻找最佳单一答案的竞赛，我想收集所有好的答案。
请阅读并评论下面“回答”中的要点。
答案 0 :(得分：5)
HTTP规范的作者Roy Fielding不同意你的看法，即CSRF是HTTP中的一个缺陷，需要在那里修复。正如他在reply in a thread named The HTTP Origin Header写的那样：
CSRF不是Web的安全问题。精心设计的网站 服务应该能够接收任何主机指示的请求， 按设计，在需要时进行适当的认证。如果浏览器 创建安全问题，因为它们允许脚本自动执行 将存储的安全凭证直接请求发送到第三方 站点，没有任何用户干预/配置，那么显而易见 修复在浏览器中。
事实上，CSRF攻击从一开始就可以使用普通的HTML。现在引入像JavaScript和CSS这样的技术只会引入更多的攻击向量和技术，使请求伪造更容易，更有效。
但它没有改变这样一个事实，即来自客户端的合法且真实的请求不一定基于用户的意图。因为浏览器会一直自动发送请求（例如图像，样式表等）并发送任何身份验证凭据。
同样，CSRF攻击在浏览器中发生，所以唯一可能的解决办法就是在浏览器中修复它。
但由于这并非完全可能（见上文），因此应用程序有责任实施一种允许区分真实和伪造请求的方案。始终传播的 CSRF令牌就是这样一种技术。并且在正确实施并且防止其他攻击时效果很好（其中许多，再次，仅在现代技术的引入下才有可能）。
答案 1 :(得分：1)
我同意其他两个;这可以在浏览器端完成，但是无法执行授权的跨站点请求。 无论如何，CSRF保护层可以很容易地在应用程序端添加（甚至可能在Web服务器端添加，以避免对预先存在的应用程序进行更改）使用类似的东西：
答案 2 :(得分：0)
对表单提交位置实施同源策略。只允许将表单提交回其来源的地方。
当然，这会打破各种其他事情。
答案 3 :(得分：0)
如果查看CSRF prevention cheat sheet，您可以看到有多种方法可以依靠HTTP协议来阻止CSRF。一个很好的例子是检查嵌入式设备上常用的HTTP referer，因为它不需要额外的内存。
然而，这是一种薄弱的保护形式。客户端上的HTTP响应拆分等漏洞可能会影响引用值，而这种情况已经发生。
答案 4 :(得分：0)
答案 5 :(得分：0)
已经可以做到了：
Referer标题这是一种较弱的保护形式。某些用户可能会因隐私目的而停用referer，这意味着他们无法在您的网站上提交此类表单。在代码中实现这一点也很棘手。某些系统允许http://example.com?q=example.org等网址传递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攻击。但是，打开整页或弹出窗口的那些会成功，但对用户来说会更加明显。