为什么浏览器允许CSRF？

Question

我对网络安全性很陌生,当我阅读更多关于不同攻击媒介的内容时,我的头脑很难说它们首先被允许.这就像网络设计的破坏安全模型一样容易受到攻击.

我也对模糊和不精确的信息感到惊讶.例如,起初单原始策略听起来不错,然后我读到它只适用于XHR,哦,顺便说一句,实际上并没有阻止XHR跨源POST,这是典型的CSRF攻击.很高兴我继续读.

还有一个Origin头,服务器可以使用它来确保请求来自正确的位置 - 但是oops,它在浏览器中设置不一致,如果没有设置,你不能确定它是否是是因为同源请求,还是某些浏览器没有得到它的请求类型(可能是IMG标签？).继续阅读.

因此,正确的方法似乎是在会话cookie中设置CSRF令牌,并将该令牌添加到表单/链接,然后在提交时将它们与服务器端进行比较.从理论上讲(并且为了这个问题而排除所有XSS攻击),来自另一个选项卡的CSRF尝试可能会对包含cookie的表单发出POST请求,但没有将表单输入元素设置为匹配令牌(因为它无法从cookie中读取令牌,因此服务器将拒绝该请求.工作但kludgy,并确保你永远不会忘记检查!

记住这一想法一秒钟,这是我的问题 - 为什么浏览器在一个请求中发送会话cookie,该请求来自不是cookie的起源的页面？

我的意思是,浏览器会拒绝将Cookie发送到不同的域名,但是很高兴从不同的来源发送它们？如果他们没有,会破碎吗？它是否是对CSRF的强大防御,只需要服务器做他们正在做的事情 - 检查有效的会话cookie？

编辑:也许这是改善情况的尝试？https://tools.ietf.org/html/draft-west-origin-cookies-01

Answer 1

我对网络安全性很陌生,当我阅读更多关于不同攻击媒介的内容时,我的头脑很难说它们首先被允许.这就像网络设计的破坏安全模型一样容易受到攻击.

都是真的.它从未被设计为首先是安全的.Web最初设计为静态文档管理和共享系统,允许直接链接到不同机器上的资源.

您今天看到的动态网络是一个kludge.我们可以使用CSRF令牌,HTTP标头等来修复它,但是如果你创建一个没有做任何这些事情的动态网站,那么它很容易受到攻击(并让像我这样的人保持工作).

在Wikipedia文章中查看其历史记录.

我也对模糊和不精确的信息感到惊讶.例如,起初单原始策略听起来不错,然后我读到它只适用于XHR,哦,顺便说一句,实际上并没有阻止XHR跨源POST,这是典型的CSRF攻击.很高兴我继续读.

也主要是真的.同源策略也适用于窗口和框架(例如,如果exam​​ple.com包含IFrame到example.org,则example.com不能通过JavaScript更改example.org的内容).是的,可以进行跨域XHR,但是如果没有启用CORS,则无法读取响应.这确实可以防止CSRF令牌被盗,但正如您所说,如果您不使用CSRF保护,则会出现CSRF漏洞.

其他防御措施(如添加自定义标头)可用于缓解CSRF,因为无法跨域发送自定义标头.

XHR以前没有能够访问任何跨域的东西,这被认为是一个太大的限制,因此CORS的出现.以前,由于表格无论如何都可以访问不同的域名,因此它并不被视为特别危险的策略.如果采取适当的控制措施,它仍然没有.

还有一个Origin头,服务器可以使用它来确保请求来自正确的位置 - 但是oops,它在浏览器中设置不一致,如果没有设置,你不能确定它是否是是因为同源请求,还是某些浏览器没有得到它的请求类型(可能是IMG标签？).继续阅读.

很正确.看到这个答案.

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

因为很多东西会破坏.有无数的表单旨在从静态站点提交到进行后端处理的动态站点.

"同站点"cookie有一个新标准.这里有一个不太干的解释.

基本上可以使用新属性设置cookie SameSite.在strict模式下,当原点不同时,不会发送cookie.在lax模式中,如果方法是例如POST,则仅保留它们,这是CSRF漏洞主要存在的地方.

你联系到的那个是早期的草案.