一次CSRF测试引发的思考

事件发生的前奏

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

https://*.huaweicloud.com/xxxx

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

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

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

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

题外小记：说下BypassX-Request-with

具体可见下图：

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

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

对于Samesite的解释。

参考一篇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会给我们带来难以置信的强大防御。