我对网络安全还很陌生，当我读到更多关于不同攻击向量的信息时，我首先想到它们是被允许的，这让我感到难以置信。这就像网络是用一个破碎的安全模型设计的，而且很容易受到攻击。
我也对大量模糊和不精确的信息感到惊讶。例如，一开始单一来源策略听起来很好，然后我读到它只适用于XHR，哦，顺便说一句，实际上并不能阻止XHR跨来源POST，这是经典的CSRF攻击。很高兴我一直在读书。
还有一个Origin头，服务器可以使用它来确保请求来自正确的位置——但哦，它在浏览器之间的设置不一致，如果没有设置，你就不能很确定它是因为相同的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
我对网络安全还很陌生，随着我阅读更多关于不同的攻击矢量，我感到难以置信的是，它们被允许进入第一名。这就像网络是在安全性崩溃的情况下设计的模型和易受攻击。
全部为真。它从一开始就没有被设计成安全的。web最初被设计为一个静态文档管理和共享系统，允许直接链接到不同机器上的资源。
你今天看到的动态网络是一个拼凑的。我们可以用CSRF令牌、HTTP头等来修复它，但如果你在不做任何这些事情的情况下创建一个动态网站，那么它很可能很脆弱(并让像我这样的人继续工作)。
在维基百科的文章中查看它的历史。
我也对大量模糊和不精确的信息感到惊讶。对于例如，一开始单一来源政策听起来不错，然后我读到它只适用于XHR，哦，顺便说一句，不适用实际上可以防止XHR跨原点POST，这是经典的CSRF袭击很高兴我一直在读书。
也主要为true。同源策略也适用于窗口和框架(例如，如果example.com包含一个到example.org的IFrame，则example.com不能通过JavaScript更改example.org的内容)。是的，可以进行跨域XHR，但如果没有启用CORS，则无法读取响应。这确实可以保护CSRF令牌不被窃取，但正如您所说，如果您没有使用CSRF保护，那么这就存在CSRF漏洞。
其他防御措施(如添加自定义标头)可用于减轻CSRF，因为自定义标头无法跨域发送。
XHR过去不能跨域访问任何内容，这被认为是一个太大的限制，因此CORS的出现。以前，由于表单无论如何都可以访问不同的域，因此这并不被视为一种特别危险的策略。只要适当的控制措施到位，情况仍然没有。
还有一个Origin头，服务器可以使用它来确保请求来自正确的位置，但哎呀，它已经设置好了在浏览器之间不一致，如果未设置，则不能很确定是因为同一来源的请求，还是一个请求类型，但在某些浏览器中没有得到它(可能是IMG标签？)。继续阅读。
没错。看看这个答案。
为什么浏览器在请求中发送会话cookie源于不是cookie来源的页面？
因为否则很多东西都会坏掉。有无数的表单被设计为从静态站点提交到进行后端处理的动态站点。
有一个新的标准；"同一站点"；饼干。这里有一个不那么枯燥的解释。
基本上，cookie可以设置为具有新属性SameSite。在strict模式下，当站点不同时，不会发送cookie。在lax模式中，只有当方法为POST时，才会保留它们，POST是CSRF漏洞的主要所在。
你链接到的是这篇文章的早期草稿。