我对网络安全性很陌生，当我阅读更多有关不同攻击媒介的内容时，我的头脑很难理解他们是首先被允许的。这就像网络设计时破坏了安全模型并且易受攻击。
我也对模糊和不精确的信息量感到惊讶。例如，起初单原始策略听起来不错，然后我读到它只适用于XHR，哦，顺便说一句，实际上并没有阻止XHR跨源POST，这是典型的CSRF攻击。很高兴我一直在读。
还有一个Origin头，服务器可以使用它来确保请求来自正确的位置 - 但是oops，它在浏览器中设置不一致，如果没有设置，你就不能完全确定是因为同源请求，还是某些浏览器没有得到它的请求类型（可能是IMG标签？）。继续阅读。
所以正确的方式似乎是在会话cookie中设置了一个CSRF令牌，并且还将该令牌添加到表单/链接中，然后在提交时将它们与服务器端进行比较。从理论上讲（并且为了这个问题而排除所有XSS攻击），来自另一个选项卡的CSRF尝试可能会对包含cookie的表单发出POST请求，但没有将表单输入元素设置为匹配令牌（因为它无法从cookie中读取令牌，因此服务器将拒绝该请求。工作但很克服，并确保你永远不会忘记检查！
记住这一想法一秒钟，这是我的问题 - 为什么浏览器会在源自不是Cookie来源的网页的请求中发送会话Cookie？
我的意思是，浏览器会拒绝将发送到不同的域名，但很高兴从发送来自不同的来源？如果他们没有，会破碎吗？它是对CSRF的强大防御，只需要服务器做他们正在做的事情 - 检查有效的会话cookie吗？
编辑：也许这是改善情况的尝试？ https://tools.ietf.org/html/draft-west-origin-cookies-01
答案 0 :(得分：9)
我对网络安全很陌生，而且我在阅读更多关于网络安全的内容时也是如此 不同的攻击向量，我的思绪令人难以置信，他们被允许进入 第一名。这就像网络设计的安全性差 模型和易受伤害。
一切都是真的。它从未被设计为首先是安全的。 Web最初设计为静态文档管理和共享系统，允许直接链接到不同机器上的资源。
您今天看到的动态网络是一个kludge 。我们可以使用CSRF令牌，HTTP标头等修复它，但是如果你创建一个没有做任何这些事情的动态网站，那么它很容易受到攻击（并让像我这样的人保持工作）。
查看its history in the Wikipedia article。
我也对模糊和不精确的信息量感到惊讶。对于 例如，起初单原始政策听起来不错，然后我 读到它只适用于XHR，哦，顺便说一下，没有 实际上阻止了XHR跨源POST，这是经典的CSRF 攻击。很高兴我一直在读。
也主要是真的。同源策略也适用于窗口和框架（例如，如果example.com包含IFrame到example.org，则example.com不能通过JavaScript更改example.org的内容）。是的，可以制作跨域XHR，但如果未启用CORS，则无法读取响应。这确实可以保护CSRF令牌免遭被盗，但正如您所说，如果您不使用CSRF保护，则会出现CSRF漏洞。
其他防御措施（例如adding a custom header）可用于缓解CSRF，因为无法跨域发送自定义标头。
XHR以前没有能够访问跨域的任何东西，这被认为是一个太大的限制，因此CORS的出现。以前，由于表格无论如何都可以访问不同的域名，因此它并不被视为特别危险的策略。如果采取适当的控制措施，它仍然没有。还有一个Origin头，服务器可以使用它来确保 请求来自正确的地方 - 但是oops，它已设置 浏览器不一致，如果没有设置，你就无法做到 确定是因为同源请求还是请求 对于某些浏览器（可能是IMG标签？），它没有获得它的类型。 继续阅读。
非常正确。请参阅this answer。
为什么浏览器会在请求中发送会话cookie 来自不是cookie原点的页面？
因为很多东西会破坏。有无数的表单旨在从静态站点提交到进行后端处理的动态站点。
有一个新的standard for "same-site" cookies。一个不太干的解释是here。
基本上可以使用新属性SameSite设置Cookie。在strict模式下，当原点不同时，不会发送cookie。在lax模式下，如果方法是例如，则仅保留它们。 POST，这是CSRF漏洞主要存在的地方。
你所关联的是早期的草案。