为什么浏览器允许 CSRF？答案

【问题标题】：Why do browsers allow CSRF?为什么浏览器允许 CSRF？
【发布时间】：2016-09-30 07:07:30
【问题描述】：

我对网络安全还很陌生，当我阅读更多关于不同攻击媒介的信息时，我开始怀疑它们是被允许的。就好像 Web 设计时使用了损坏的安全模型并且容易受到攻击。

我也对大量模糊和不精确的信息感到惊讶。例如，起初 Single Origin Policy 听起来不错，然后我读到它只适用于 XHR，顺便说一句，它实际上并不能阻止 XHR 跨域 POST，这是经典的 CSRF 攻击。很高兴我一直在阅读。

还有一个 Origin 标头，服务器可以使用它来确保请求来自正确的位置——但是糟糕，它在浏览器之间的设置不一致，如果没有设置，你就不能完全正确确定是因为同源请求，还是某些浏览器无法获取的请求类型（可能是 IMG 标签？）。继续阅读。

所以正确的方式似乎是在会话cookie中设置一个CSRF令牌，并将该令牌添加到表单/链接中，然后在提交时比较它们的服务器端。理论上（为了这个问题，我们排除所有 XSS 攻击），来自另一个选项卡的 CSRF 尝试可能会向包含 cookie 的表单发出 POST 请求，但没有将表单输入元素设置为匹配的令牌（因为它无法从 cookie 中读取令牌），因此服务器将拒绝该请求。工作但很笨拙，并确保您永远不会忘记检查！

暂时记住这个想法，这是我的问题——为什么浏览器会在来自不是 cookie 来源的页面的请求中发送会话 cookie？

我的意思是，浏览器会出于充分的理由拒绝将 cookie 发送到不同的域，但很乐意将它们发送来自不同的来源？如果他们不这样做，东西会破裂吗？它会不会是针对 CSRF 的强大防御，只要求服务器做他们正在做的事情——检查有效的会话 cookie？

编辑：也许这是为了改善这种情况？ https://datatracker.ietf.org/doc/html/draft-west-origin-cookies-01

【问题讨论】：

很多东西都会坏掉。例如所有这些分析和广告脚本。
浏览器并不是从一开始就设计为允许 CSRF发生的。 CSRF 是后来发现的，当时已经有很多网站了。肯定不止十个。事后更改规则并期望每个网站都进行更改以适应规则更改是期望很高的-尤其是当很多跨站点请求可能没有有害影响时，只有理想的。
这有点无关紧要。网站有责任保护自己，而不是依赖“正确”设计/开发/维护的浏览器。这就是为什么 CSRF 令牌（即使是笨拙的）是必要的。我建议将 CSRF 构建到网站架构中（或使用已有的框架）。这样，它总是在那里并且总是被检查（假设你正确使用了框架；）
@LaJmOn 需要保护的不是用户，而不是网站吗？并且用户希望他们的浏览器通过保护他们来自一个站点的 cookie 免受来自另一个站点的请求来保护他们？就像它希望浏览器也以许多其他方式保护它们一样。
这篇文章比较老了，但只想说——太棒了！

标签： security web csrf csrf-protection

【解决方案1】：

我对网络安全还很陌生，当我阅读更多关于不同的攻击向量，我难以置信他们被允许在第一名。就像网络被设计时安全性被破坏一样模型和易受攻击。

都是真的。它从一开始就没有被设计成安全的。 Web 最初被设计为一个静态文档管理和共享系统，允许直接链接到不同机器上的资源。

您今天看到的动态网络是一个杂物。我们可以使用 CSRF 令牌、HTTP 标头等来修复它，但如果您创建一个动态网站而不做任何这些事情，那么它很可能很容易受到攻击（并且让像我这样的人继续工作）。

查看its history in the Wikipedia article。

我也对大量模糊和不精确的信息感到惊讶。为了例如，起初 Single Origin Policy 听起来不错，然后我读到它只适用于 XHR，哦，顺便说一句，不实际上是防止 XHR 跨域 POST，这是经典的 CSRF 攻击。很高兴我一直在阅读。

也大体如此。同源策略也适用于窗口和框架（例如，如果 example.com 包含对 example.org 的 IFrame，则 example.com 不能通过 JavaScript 更改 example.org 的内容）。是的，可以制作跨域 XHR，但如果不启用 CORS，则无法读取响应。这确实可以保护 CSRF 令牌不被盗，但正如您所说，如果您不使用 CSRF 保护，那么这会带来 CSRF 漏洞。

adding a custom header 等其他防御措施可用于缓解 CSRF，因为无法跨域发送自定义标头。

XHR 过去不能跨域访问任何东西，这被认为是一个太大的限制，因此出现了 CORS。以前，由于表单无论如何都可以访问不同的域，因此它并不被视为特别危险的操作。如果采取了适当的控制措施，它仍然不是。

还有一个 Origin 标头，服务器可以使用它来确保请求来自正确的地方——但是糟糕，它已经设置好了跨浏览器不一致，如果未设置，则不能很确定是同源请求还是请求某些浏览器无法获取的类型（可能是 IMG 标签？）。继续阅读。

非常正确。见this answer。

为什么浏览器会在请求中发送会话 cookie 源自不是 cookie 来源的页面？

因为否则很多事情都会崩溃。有无数的表单旨在从静态站点提交到执行后端处理的动态站点。

有一个新的standard for "same-site" cookies。一个不那么干巴巴的解释是here。

基本上可以使用新属性SameSite 设置cookie。在strict 模式下，站点不同时不会发送cookie。在lax 模式下，仅当方法为例如POST，这也是 CSRF 漏洞主要存在的地方。

你链接的那个是这个的早期草稿。

【讨论】：

“有无数的表单被设计为从静态站点提交到执行后端处理的动态站点”——但是跨域？如果是这样，他们只是假设另一个窗口已将 cookie 设置为目标站点？我试图想到这样的例子，但找不到任何例子。 SameSite cookie 听起来很有趣，希望它尽快成为标准。
联合单点登录是一个示例，有时会为每个会话创建一个随机数，当流重定向回站点时可以验证该随机数。例如Site --> Set Cookie -> Redirect to OpenID Provider --> Authenticate --> Redirect back with claim --> 站点检查 nonce cookie 并声明。
@aaa90210 同源策略永远不会阻止请求的发生，它们只会阻止响应被 javascript 读取。
@SilverlightFox 这不是错的吗'起初单源策略听起来不错，然后我读到它只适用于 XHR，'，它也适用于图像。还有很多是无法读取图片数据的，如果用canvas读取会报错。
@sur 它也适用于图像。