<
一次CSRF测试引发的思考
>
上一篇

SSRF在有无回显方面的利用及其思考与总结
下一篇

2019工业信息安全竞赛部分-writeup

一次CSRF测试引发的思考

原创:芳华

事件发生的前奏

在一次CSRF测试中,绕过了一切防护,原本以为快要成功了然而事情并没有那么简单。。。。

https://*.huaweicloud.com/xxx/xxxx.html

1568166415201

我说这个地方有csrf,但是有点奇怪

1568166701078

1没关系 2可删除,你bp可以重放一个cookie正确的referer删除掉,origin换成你本地ip

登陆状态下点了之后会提示说未登陆导致csrf post不成功,origin referer都没验证,这个站同一个浏览器里点了cookie会改变

1568166515847

别的一般bypass 了 referer token origin X-Request-with基本就成功了。

题外小记说下BypassX-Request-with

具体可见下图:

img1

img2

其中BypassX-Request-With-POC为上图测试中用到的POC

某SRC img2

于是,进入沉思,找到原因才能找到解决办法。又仔细查看浏览器的数据包,最后找到了这个

1568166760258

对于Samesite的解释。

1568166840930

参考一篇Samesite文章,看完后顿时又卡了,再一次进入了沉思。。。。

跨站请求伪造真的死了?

​ 脑补了SameSite防护机制后,可以知道若SameSite cookie设置为严格模式,点击链接到打开站点时,将无法登录。无论是否已登录,在新标签中打开,无论您做什么,都不会从该访问的链接登录到站点。而在该测试中的上面网站已将SameSite保护设置为Lax模式,可以解决用用户点击链接时严格模式中所遇到的问题,如果他们已经登录,则不会在目标站点上再次需要登录。

​ 在Lax模式下,只有一个例外允许cookie到附加到使用安全HTTP方法的顶级导航。“安全”HTTP方法在RFC 7321的4.2.1节中定义为GET,HEAD,OPTIONS和TRACE。此处的GET方法引起了我的注意。按照GET方法在定义中的解释,也就意味着,登陆情况下,浏览到顶级的https://target.com域名网站,当用户点击链接时,浏览器发出请求时会附加了SameSite标记的cookie,从而保持了预期的用户体验。当然,我们还完全受到基于POST的CSRF攻击的保护。回该测试中,并简化一下CSRF POC,此攻击仍然无法在Lax模式下工作。

<form action="https://your-bank.com/transfer" method="POST" id="stealMoney">
<input type="hidden" name="to" value="Scott Helme">
<input type="hidden" name="account" value="14278935">
<input type="hidden" name="amount" value="£1,000">

由于POST方法不被认为是安全的,因此浏览器不会在请求中附加cookie。由此解答了沉思中的一点疑惑了解了问题的症结。

我又提出了新问题——So,存在绕过吗?

答案是:可以的,但有条件。

又继续找了下资料,若网站接受GET请求代替POST请求,那么,攻击者当然可以自由地将方法更改为“安全”方法并发出相同的请求。

<form action="https://your-bank.com/transfer" method="GET" id="stealMoney">
<input type="hidden" name="to" value="Scott Helme">
<input type="hidden" name="account" value="14278935">
<input type="hidden" name="amount" value="£1,000">

防护:

​ 只要我们不接受GET请求代替POST请求,那么这种攻击是不可能的,但是在Lax模式下操作时需要注意。此外,如果攻击者可以触发顶级导航或弹出新窗口,他们还可以使浏览器发出附加了cookie的GET请求。这是在Lax模式下运营的权衡,我们保持用户体验不变,但接受付款的风险很小。

​ 将SameSite属性添加到cookie中。它形成了一个非常好的防御深度方法。我们可以考虑删除传统的反CSRF机制,但是在这些机制之上添加SameSite会给我们带来难以置信的强大防御。

Top
Foot