每日漏洞 | 跨站请求伪造 – 作者:noobsec

01 漏洞描述



HTTP的无状态性,导致Web应用程序必须使用会话机制来识别用户。一旦与Web站点建立连接(访问、登录),用户通常会分配到一个Cookie,随后的请求,都会带上这个Cookie,这样Web站点就很容易分辨请求来自哪个用户,该修改哪个用户的数据。如果从第三方发起对当前站点的请求,该请求也会带上当前站点的Cookie。正是这是这个缺陷,导致了CSRF的产生,利用这个漏洞可以劫持用户执行非意愿的操作。

02 漏洞检测



CSRF的利用场景常常是在用户已登录的情况下,伪造用户意愿从站外发起请求。更深入剖析:请求能从站外发起(跨站)、请求的参数和值可以伪造(伪造请求),因此,CSRF的检测也是从这两点入手。

以转账为例,输入账户和金额,点击Transfer即可完成转账。我们检测该功能是否存在CSRF。

1-csrf.jpg

是否可跨站

要检测是否可跨站,只需要操作请求头中的referer字段即可。referer字段记录了请求的来源,如果请求头中没有referer字段,或者删掉请求头中的referer字段,均响应成功,那么服务器就没有校验请求来源,存在“跨站”。

首先正常提交请求包,发现转账成功。

2-csrf.jpg

我们可以看到请求头中有个Referer字段,其中的值表示我们是从哪个页面请求过来的。我们试着将Referer字段删除并再次提交,查看账户余额有没有变化。

3-csrf.jpg

发现账户余额从990变成980,说明服务器并没有验证请求来源,可以“跨站”。

是否可伪造请求

伪造请求的前提是,我们知道如何去伪造请求中的参数和值,也就是说我们知道请求中包含哪些参数,知道参数的准确值或者范围。因此,检测是否可伪造请求,只需要查看请求中是否有我们无法伪造的参数和值即可。

4-csrf.jpg

可以看到,请求中有4个参数,account表示账号,amount表示转账金额,这两个很好伪造,action表示执行的动作,不需要伪造,直接使用即可。token是什么东西?(Token令牌了解一下)

token参数的值这么长,一看就知道不好伪造。那删掉token试试,万一和referer字段一样,服务器没有对token进行校验呢。

5-csrf.jpg

反复重放了几次请求,发现账户余额保持不变,很显然,token参数必须有。那我们随便改一下token的值,看请求中是不是只要有token参数就行了,但服务器并不会校验token的值。

6-csrf.jpg

反复重放几次,发现账户余额依然保持不变,说明服务器对Token做了校验,请求中不能缺失token或token错误。

正打算放弃的时候,无聊的重放着原始请求包,突然发现账户余额变成了900。

7-csrf.jpg

WTF,同一个token值好像可以反复使用,均能通过校验,难道这token是永久的?后来发现只要不退出重新登录,token会一直有效,了解了,这叫“韩式半永久”。

验证CSRF

既能“跨站”,又能伪造请求,那CSRF的验证就很简单了。重新抓包,利用抓包工具生成CSRF的POC。

8-csrf.jpg

9-csrf.jpg

复制其中的HTML代码,在本地新建一个HTML页面,将复制的代码保存其中,然后在同一个浏览器中打开(不懂的请gun去学习Cookie方面的知识)。

10-csrf.jpg

点击CSRF页面中的按钮,发现会跳转到转账页面,且账户余额只有400,少了500。 

11-csrf.jpg12-csrf.jpg


CSRF的检测到此圆满结束。至于CSRF的利用,简单说两句,可以构造一个链接(GET)、隐藏的表单(POST)、图片等,然后想方设法让用户点击或访问就可以了。  

03 漏洞修复



请求来源验证;HTTP请求头中有个referer字段,该字段记录了当前HTTP请求的来源。可以通过检查请求是否来自站外,来防御站外发起的CSRF,但不能防御从站内发起的CSRF,且存在被绕过的风险。

Token验证;在请求中添加攻击者无法预测的Token令牌,当请求中缺失Token或Token值不对时,则拒绝请求。请使用一次性的Token,而且记得及时更新,不然还是可以绕过。(这种情况工作中已经遇到过无数次了)

使用图形验证码,但可能会影响用户体验。

04 PS


我这里举了一个既包含referer又包含token的例子,为了让大家更好的理解CSRF的检测,排版可能会与实际情况有些出入。实际工作中,我个人习惯先多次重放,看token是否可重复使用,如果可重复使用,自然不用修改token值或删除,只需要检测是否可“跨站”即可;如果不能重复使用,说明会校验token值,那么就不必修改token值,只需直接删除token试试,最后再测试是否可“跨站”。而且在实际利用中,token值的获取没有这么简单。只是在检测过程中,我们发现token机制存在缺陷,那我们应该防患于未然,将风险降低到零。这里简要解释一下文章内容与实际工作中相出入的几点。

文章风格,尽量简单明了,再以幽默风趣的方式给大家介绍漏洞的检测。个人觉得我的校友们应该能看懂,如果实在是忙于做菜和开挖掘机,没时间看懂,可以在公众号里留言,有时间我就会回复。新开的公众号,文章底部暂不支持留言,这个有点头疼。每日漏洞系列需要校友们有一定基础,定位也是定在如何检测,所以理论的东西不会介绍太多,校友们平时可以适当补充理论知识,这样更容易消化每日漏洞的内容。

来源:freebuf.com 2019-05-06 13:12:00 by: noobsec

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论