「Burpsuite练兵场」CSRF(二)

  • A+
所属分类:安全文章

「Burpsuite练兵场」CSRF(二)


Burpsuite练兵场系列文章更新啦,今天的内容是延续上期关于CSRF的内容介绍,感兴趣的小伙伴千万别错过了呦!



上期回顾

「Burpsuite练兵场」CSRF(二)

「Burpsuite练兵场」CSRF(一)


「Burpsuite练兵场」CSRF(二)


本文是 i 春秋论坛作家「dll_s」表哥原创的Burpsuite练兵场系列文章,公众号旨在为大家提供更多的学习方法与技能技巧,文章仅供学习参考。


「Burpsuite练兵场」CSRF(二)


实验一:Token关联到非会话cookie


实验提示:应用程序 email change模块存在CSRF漏洞,启用了token防护,但是并未将csrf令牌防护整合到会话管理中。


实验要求:构造CSRF利用代码并上传到exploit server中。


「Burpsuite练兵场」CSRF(二)


这里如果看了Burpsuite学院中的相关说明,就会明白它的原理,下面跟随实验进行讲解。


分别使用提供的两个账号进行登录,并使用email change功能,观察这两个请求报文。


「Burpsuite练兵场」CSRF(二)

「Burpsuite练兵场」CSRF(二)


可以发现,cookie中的seesion字段值发生了改变,但csrfKey字段以及csrf字段值均未变化。


这说明什么含义呢?session负责会话管理,根据不同账户刷新字段值;csrfKey以及csrf用于防范csrf攻击,可能是根据浏览器会话或者是IP地址更新值。


这从某种角度来说也是可以成功防范csrf攻击的,因为我们无法构造POC对Cookie中的csrfKey参数进行单独操纵。


但是在这个web应用中,还存在另一个利用点,在home页面的搜索框中存在注入点,让我们来观察一下请求流。


「Burpsuite练兵场」CSRF(二)


可以看到,我们的输入触发了服务器的Set-cookie操作,将搜索参数LastSearchTerm=123附加到了Cookie中。


因此就可以构造输入,将csrfKey参数注入到受害者的访问会话中。

需要注入的内容
test
Set-Cookie: csrfKey=oTUybWBc3MlhcrCkNTqy8tPpJI62V6hg
经过URL编码
test%0D%0ASet-Cookie%3A%20csrfKey%3DoTUybWBc3MlhcrCkNTqy8tPpJI62V6hg

同样,使用Burpsuite自动生成CSRF POC,然后修改javascript自动提交代码,通过图片方式构造有效POC。

<img src="https://ac391fd21f1b1d0a802d0871007400a9.web-security-academy.net/?search=test%0D%0ASet-Cookie%3A%20csrfKey%3DoTUybWBc3MlhcrCkNTqy8tPpJI62V6hg" onerror="document.forms[0].submit()">

此<img>标签会先请求src中的地址,成功注入csrfKey,之后由于图片地址不存在执行onerror中的js代码提交表单。


「Burpsuite练兵场」CSRF(二)


将POC保存到exploit server中完成实验。


点击View exploit可以进行验证,观察流可以看到成功注入了csrfKey字段。


「Burpsuite练兵场」CSRF(二)


实验二:利用Token双重提交防范CSRF


实验提示:应用程序 email change模块存在CSRF漏洞,应用程序使用的"double submit"(双重提交)防护存在问题。


实验要求:构造CSRF利用代码并上传到exploit server中。


「Burpsuite练兵场」CSRF(二)


这里提到了一个double submit防范方式,其具体原理为:Web应用不维护已发出令牌的任何服务器端记录,而是在一个cookie和一个请求参数中复制每个令牌,在验证后续请求时,应用程序只需验证在请求参数中提交的令牌是否与在cookie中提交的值匹配,这样一来就避免了任何服务器端状态的需要,因此也是一种不错的实现方式。


然而在这个实验环境中之所以能够进行CSRF攻击,是因为与上一个实验一样,搜索框中存在注入点,我们可以注入想要的Cookie头中的csrf字段。


所以前面的操作流程大致相似,利用Burpsuite生成POC,不同点在于注入点的代码。

需要注入的内容
test
Set-Cookie: csrf=nN0hiejOg5KXMbn4N94PiDfzuzZbWnhN
经过URL编码
test%0ASet-Cookie%3A%20csrf%3DnN0hiejOg5KXMbn4N94PiDfzuzZbWnhN

<img>标签构造

<img src="https://ac771f4b1fc23bf1809447d500330029.web-security-academy.net/?search=test%0ASet-Cookie%3A%20csrf%3DnN0hiejOg5KXMbn4N94PiDfzuzZbWnhN" onerror="document.forms[0].submit()">

「Burpsuite练兵场」CSRF(二)


将POC保存到exploit server完成实验。


实验三:默认Referer头存在导致CSRF攻击


实验提示:应用程序email change模块存在CSRF漏洞。


实验要求:构造CSRF利用代码并上传到exploit server中。


「Burpsuite练兵场」CSRF(二)



什么叫做基于Referer头的防范呢?HTTP报文中的Referrer 头大家应该都熟悉,它会显示当前文档的来源文档的URL,所以程序可以通过判断该值是否为所要求的URL来防范csrf攻击。但是一些Web程序会默认此头存在,以此导致如果我们删除了referer头,判断逻辑就会失效,csrf攻击仍然可以成功执行。


知道了原理,实验就好操作了。同样登录账户,来到email change页面修改邮箱,并根据报文生成CSRF POC,我们通过 <meta> 标签来指定 Referrer 策略,将如下代码插入到poc中,以达到去掉Referer头的效果。

<head>
<meta name="referrer" content="no-referrer">
</head>

「Burpsuite练兵场」CSRF(二)


将POC保存到exploit server完成实验。


关于插入代码的详细原理可以查看这篇文章:Referrer Policy 介绍。


实验四:Referer验证失效导致CSRF攻击


实验提示:应用程序email change模块存在CSRF漏洞,虽然程序尝试检测并阻止跨站请求但仍然可以被绕过。


实验要求:构造CSRF利用代码并上传到exploit server中。


「Burpsuite练兵场」CSRF(二)


这一实验中,web对Referer进行了验证,但是验证方式存在逻辑漏洞。


一些应用程序以一种可以绕过的简单方式验证Referer头。例如,如果应用程序只是验证Referer是否包含自己的域名,则攻击者可以将所需的值放在URL中的其他位置。

http://attacker-website.com/csrf-attack?vulnerablewebsite.com

如果应用程序验证Referer中的域以预期值开始,则攻击者可以将其作为自己域的子域。

http://vulnerablewebsite.com.attacker-website.com/csrf-attack

了解了验证机制问题,我们就可以着手进行突破了。

https://acbd1fa31ed4a32f804b0be500dc0085.web-security-academy.net   #这是正常email-change报文中有效的referer值
https://ac851fb31fcd35a380b9005b01420064.web-security-academy.net   #这是我们的exploit server地址

这里可以尝试能否使用<img>改变Referer源。

<img src="https://acbd1fa31ed4a32f804b0be500dc0085.web-security-academy.net/email" onerror="document.forms[0].submit()">

验证可以发现Referer值仍然为我们的exploit server地址,更改失败。


这里就要用到一个新的技巧:


history.pushState(state, title[, url]) 用于插入一条历史记录。

history.pushState(state, title[, url])
state:javascript对象,与pushState所创建的条目相关联,传入的值可以是任何可序列化对象
title:大多数浏览器目前忽略这个参数,建议传递空字符串
url:传递的值必须与当前url同域,可以使用相对于当前url的相对路径

这一函数的作用其实在之前就已经可以初见端倪。


观察这个报文流,你是否会感觉很奇怪,为什么图中标黄的报文Referer值并不是/exploit路径。


「Burpsuite练兵场」CSRF(二)


没错,原因就是因为我们利用POC插入了一条历史记录使得Referer值也随之更改。


「Burpsuite练兵场」CSRF(二)


注意:这一函数是存在跨域限制的,即我们只能插入exploit server域的地址,所以我们的构造方式是这样。

history.pushState('', '', '/?acbd1fa31ed4a32f804b0be500dc0085.web-security-academy.net')

通过将正确的Referer值附着到exploit server域后以此欺骗验证以实施成功的csrf攻击。


「Burpsuite练兵场」CSRF(二)


将POC保存到exploit server完成实验


总结


CSRF的实验到这里就结束了,通过实验我们也基本可以总结出如何有效的防范此类攻击:


  • 使用Token,注意需要保证Token的不可预测性以及会话关联性;


  • 也可以利用文所描述的中double submit机制;


  • 验证Referer头,注意不要使用简单验证;


  • 不要忽略任何验证参数不存在的情况,以及任何不同的请求方式。


今天的文章分享,小伙伴们看懂了吗?


文章素材来源于i春秋社区


如果想要系统全面学习网络安全课程,可以报名i春秋培训学院的渗透测试工程师线下就业班北京+成都两地同时开启秋季线下招生,现在报名即可享受开学季超值优惠!

「Burpsuite练兵场」CSRF(二)


「Burpsuite练兵场」CSRF(二)


更多课程咨询,识别下方二维码,培训老师一对一为您解答疑惑!


快速咨询入口

「Burpsuite练兵场」CSRF(二)

「Burpsuite练兵场」CSRF(二)



因为公众号平台改变了推送规则,文章的更新不再按照推送时间排序,如果想及时查看安全技能相关文章,请这样操作:

1、在每一次阅读后点“在看”;

2、设为星标, 点击公众号名称“i春秋”,再点右上角的“...”,点“设为星标”🌟

 

「Burpsuite练兵场」CSRF(二)


文末下方点个在看


「Burpsuite练兵场」CSRF(二)

i春秋官方公众号为大家提供

前沿的网络安全技术

简单易懂的实用工具

紧张刺激的安全竞赛

还有网络安全大讲堂

更多技能等你来解锁

「Burpsuite练兵场」CSRF(二)


「Burpsuite练兵场」CSRF(二)

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: