通过本篇文档我们可以更为接近实战的去学习和了解什么是CSRF漏洞、CSRF漏洞是到底如何产生的、在实际场景中被利用是如利用,以及一些在web安全测试用常用插件与工具的使用和技巧。本篇文稿中给出了两个场景的CSRF漏洞的利用过程复现:
(1)密码修改过程中产生的CSRF漏洞和利用
(2)后台管理添加过程中产生的CSRF漏洞和利用
文稿最近简单的罗列了下当前常用的避免csrf漏洞产生的方法和措施。
1、CSRF 基本概念
CSRF(Cross-site request forgery)跨站请求伪造,黑客利用已经登录的用户,诱使其访问或者登录某个早已构造好的恶意链接或者页面,然后在用户毫不知情的情况下,以用户的名义完成了非用户本意的非法操作。这种攻击我们也被称为"One Click Attack"或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用行为。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。
2、CSRF 学习理解
其实一个CSRF漏洞攻击的实现,其需要由“三个部分”来构成。
(1) 有一个无需后台验证的前台或后台数据修改或新增请求的漏洞存在;
(2) 伪装数据操作请求的恶意链接或者页面;
(3) 诱使用户主动访问或登录恶意链接,触发非法操作;
2.1 第一部分:漏洞的存在
关键字:跨站请求漏洞存(CSR:Cross Site Request)
如果需要CSRF攻击能够成功,首先就需要目标站点或系统存在一个可以进行数据修改或者新增操作,且此操作被提交后台后的过程中,其未提供任何身份识别或校验的参数。后台只要收到请求,就立即下发数据修改或新增的操作;
以上漏洞情况的存在,出现比较多的场景有用户密码的修改、购物地址的修改或后台管理账户的新增等等操作过程中。
2.2 第二部分:漏洞利用的伪装
关键字:伪装请求(F:forgery)
CSRF漏洞存在了,如果需要真正的被利用,还需要对“修改或新增”数据操作请求的伪装,此时恶意攻击者只要将伪装好的“数据修改或新增”的请求发送给被攻击者,或者通过社工的方式诱使被攻击者在其cookie还生效的情况下点击了此请求链接,即可触发csrf漏洞,成功修改或新增当前用户的数据信息,如修改当前用户的密码、又或者是当前用户为后台管理员,触发漏洞后新增了一个后台管理员。
2.3 第三部分:用户非本意的操作
关键字:非本意操作
当前用户在不知情的情况下,访问了黑客恶意构造的页面或在链接,即在非本意的情况下完成黑客想完成的“非法操作”,实现了对当前用户个人信息的恶意操作。
2.4 CSRF 漏洞理解小结
小结:构造一个恶意链接或者html页面
说一千道一万,我们要明白“CSRF漏洞的目的”是什么,其实就是利用已存在的漏洞构造了一个“恶意链接”或“html页面”,然后诱使用户点击触发此漏洞。
那么说的再明白点,就是被检测的目标站点存在一个漏洞(CSRF),攻击者利用此类漏洞伪装了一个链接或者html页面,诱使被攻击者在登录的情况下(即当前cookie有效的情况下)点击了此伪装请求,随后在用户不知情的情况下完成了对当前用户数据的修改或者新增操作,而被修改的信息可能是用户的密码、关键信息又或者新增后台管理员等。
3、CSRF 场景重现
以上说了这么多,都是在说基本概念的理解,接下来我会带着大家一起在实际中看看CSRF漏洞比较容易出现的地方,我们是如何一步一步发现这个漏洞和怎么利用它的,请大家屏住呼吸跟我来吧…
注:本篇文档主要给大家带来两个场景利用分析与学习。
3.1 密码修改之 CSRF 漏洞场景重现
有关于CSRF漏洞特别容易出现的地方就是有关用户信息数据修改的地方了,其中在一些商城网站平台出现最多的有用户密码的修改、邮寄地址的修改和账户转账等处,这里我们以用户密码修改为例,带着大家一起看看CSRF漏洞的产生过程以及怎么构造恶意链接和html页面。
为了大家自己动手练习,这以DVWA演练平台为演示环境,来跟大家一起学习下CSRF之用户密码修改漏洞的始末。
3.1.1 DVWA 漏洞环境搭建
有关于DVWA漏洞平台的搭建,这里不做过多的说明,具体内容大家可以参加网上的文章,参考搭建,这里给出相关参考链接。
参考链接: 参考链接
DVWA环境准备好后,我们即可直接输入用户名密码登录平台进行演练。(默认账号密码:admin/passowrd)
3.1.2 CSRF 漏洞之密码修改过程
我这里使用DVWA 的low 级别中的CSRF漏洞之密码修改,带着大家一起看看漏洞到底是什么样子的,首先先我们先看看存在CSRF漏洞环境下,密码的修改过程是怎样的。
(1) 进入密码修改界面
我们直接登录DVWA平台后,设置当前演练等级security=low级别,点击CSRF来到修改密码的操作界面;
(2) 修改当前用户admin密码
来到用户名密码修改界面后,我们发现当前修改页面操作很简单,直接输入新密码,做两次确认输入提交即可,无任何其他限制和要求;
(3) 密码修改后登陆确认
我在修改完用户名密码后,直接登出平台,做一次重新登陆,验证下用户密码是否修改成功。(这里我把表单passowrd字段的类型“password”去掉后,可以直接看到当前用户名密码的明文为123,点击提交后成功登陆,说明密码修改成功。)
3.1.3 CSRF 漏洞之发现分析
接下来我们通过专业的抓包工具,分析下密码修改过程中,数据的请求与提交过程,我们具体做了哪些动作。
3.1.3.1 burpsuite 抓包分析
(1)工具准备
•firefox 浏览器
•代理插件foxyproxy
•burpsuite 工具箱
firefox火狐浏览器没什么可说,burpsuite 抓包工具,同样大家肯定都是耳熟能详的,如果有不太了解的,建议大家还是找些资料去学习下,此工具应该是搞web安全人员的随身必备工具。
(2) foxyproxy 代理插件配置
这里只简单的说下有关foxyproxy插件配置,我们直接去firefox插件扩展中进行搜索,下载安装即可,配置也比较简单。只要右击菜单栏中foxyproxy图标,选择“选项” - 选择工作模式“为全部URLs启用代理服务器” - 选中“默认代理” - 点击“编辑选中项目” - 添加代理的“IP地址”与“端口”即可。
以后每次使用代理时,只需要简单选择下配置选项即可,简单好用,推荐使用。
(3) burpsuite 抓包详解
OK,废话不多说,工具准备好了,咱们进入正题吧。
首先我们开启代理配置,打开burpsuite抓包工具,开启拦截模式,正式进行抓包模式。
通过burpsuite的抓包分析,我们可以发现整个修改密码的过程中,请求数据包中只携带了两个关键性的参数:
密码修改的3对 key:value值:password_new、password_conf、Change
当前用户的cookie值:PHPSESSID、Security
除此以外,整个密码修改的请求数据包中再也没有任何其他可以证明或者校验客户端请求的内容了,也就是因为没有任何其他的校验的存在,为黑客后续“跨站请求伪造”提供了可乘之机,也是漏洞产生的主要原因。
3.1.3.2 tamper data 抓包分析
当然除了是使用burpsuite抓包工具以为,我也可以使用其他的工具进行web请求内容的抓包与分析,这里简单在给大家分享一个使用 tamper data插件抓包改包的分析工具。
(1) 工具准备
firefox 浏览器
tamper data 扩展插件
(2) tamper data 改包插件安装
tamper data 抓包改包工具,也是firefox浏览器扩展插件之一,故我们只要去扩展插件中搜索下载安装即可。
(3) tamper data 抓包分析
3.1.4 CSRF 漏洞利用
3.1.4.1 恶意链接伪造
对于挖掘目标站点存在密码修改的csrf漏洞后,我们如何利用它就是关键了,最简单的方法就是使用burpsuite抓包后,提取密码修改操作的GET请求的URL,然后通过相应的处理后,结合社工的方法诱骗他人点击链接,修改他人的账号密码信息,有关具体操作参见如下。
(1) 截断请求包,提取URL请求
URL提取值: URL提取值
(2)URL 链接伪装
在提起到存在csrf漏洞的URL请求后,我们可以直接把此URL进行缩短处理,进行简单的伪装处理后,结合社工的方法诱使被攻击对象点击触发漏洞利用。
3.1.4.2 恶意html表单伪造
伪造一个html页面相对上面简单的伪装一个链接来说,相对就更显高高级了,使用起来也更专业了,相对成功率也更高。这里收简单的描述下伪造html也的过程,后面会贴出每一步的具体操作。
•第一步:提取密码修改的URL请求;
•第二步:依照URL请求的格式,伪造一个form表达;
•第三步:诱使被攻击者点击恶意的html连接;
(1) 提取密码修改的URL请求
我们可以借助抓包工具burpsuite抓取密码修改操作的数据包,分析数据包的请求内容。
(2) 伪造form 表单
在分析修改密码数据请求内容后,我们可以手动构造一个简单的html表单页面,为csrf攻击做好准备;
(3) 诱使被攻击者点击恶意html链接
我们将构造好的html表单页面放到一个网上,然后通过社工的方式发送给被攻击者,诱使他访问此恶意页面出发“账号密码修改操作”。
3.1.5 CSRF 密码修改漏洞小结
CSRF密码修改漏洞小结:通过上面的分析与学习的展开,我们可以发现这种场景漏洞的存在,其实比较好发现。其他特点就是“用户密码的修改无任何的条件限制与校验机制”。
3.2 后台管理员新增之 CSRF 漏洞重现
我们在做渗透测试时,也会经常进行一些CMS系统的“黑盒测试”,就是自己搭建目标系统的CMS系统,然后本地进行前台和后台的所有功能安全测试,挖掘可能存在的漏洞。其中我们对于“后台账号的添加系统管理员”一项操作,进行csrf漏洞的挖掘就很有必要,如果我能够挖掘出此漏洞,我们就可以构造恶意的html表单页面对真是的目标“CMS系统”进行攻击,为我们在真实的目标系统上添加一个后台管理员,拿下其后台管理权限,为进一步的渗透打开大门。接下来的漏洞复现,就以一个小众的CMS系统进CSRF 添加后台管理账号漏洞的复现。
3.2.1 环境准备
phpstudy web容器环境准备
burpsuite 抓包工具
lvyecms 系统下载
3.2.2 phpstudy web容器环境
有关于phpstudy web容器环境的搭建,这里不做过多的说明,因为真的很简单,大家直接下载默认安装即可使用。
下载地址:
3.2.3 burpsuite 抓包工具
burpsuite 抓包工具与代理插件的使用,可参加上面的3.1章节的内容,这里也不在重复说明了。但是多说一句burpsuite 工具箱真的很强大,强烈建议大家拥有,后面还还给大家演示怎样使用burpsuite进行一键构造一个csrf 的POC表单,我也是刚刚学会的,后面演示复现时会分享给大家。
3.2.4 lvyecms 环境搭建
3.2.4.1 解压源码包
在phpstudy web容器环境准备好后,我们直接将lvyecms源码包解压重新命名(lvyecms),然后将解压包复制到phpstudy主目录下的WWW文件夹下即可。
3.2.4.2 站点域名设置
为了后续的对测试环境的访问,我简单的设置下“站点域名设置”,具体设置如下。
选择“其他选项菜单” - “站点域名管理” - 添加“网站域名”www.lvye.com
- 设置“网站目录” E\phpstudy\www\lvyecms
,然后点击新增,最后保存设置重启服务。
3.2.4.3 配置hosts主机解析文件
我直接进入目录“C:\Windows\System32\drivers\etc”找到hosts文件,在文件中添加一条解析记录
127.0.0.1 www.lvye.com
,然后保存即可。(注意以管理员权限打开文件才能修改成功)
3.2.5 后台管理添加过程测试
(1) 进入添加后台管理员界面
(2) 添加后台管理员test
(3) 确认管理员添加情况
3.2.6 CSRF 漏洞发现分析
通过以上三步简单的操作,我们即可完成一个后台管理员账号的授权添加,并没发现什么异常,接下来我们将使用burpsuite进行抓包分析下正添加管理账号的请求过程中是否存在未对用户做除cookie以外的有效身份验证操作。
(1) 配置好firefox 代理设置安全漏洞。
(1) 配置好firefox 代理设置
有关firefox浏览器中foxyproxy代理设置插件的使用,请参加3.1章节内容。
(2) 开启burpsuite 数据包代理截断
(3) 请求包抓包分析
通过抓包分析可以看到,在我们进行后台超级管理员添加的过程发送出去的请求只包两类关键信息:
包含了当前用户的cookie值
添加管理员相关信息参数;
除去以上两个信息再无其他任何对当前用户身份进行有效校验的信息。因此,推断此处添加管理员的操作可能存在csrf漏洞。
(4) 直接构造get类型的csrf恶意链接
构造方法比较简单,我们直接在burpsuite 截断数据出右击鼠标,选择“”,随后右击鼠标“copy url”即可获取一个完整的get类型的“添加管理操作”的URL请求;
通过验证,发现构造的get类型csrf恶意链接并不能添加管理员,由此可以推断index.php脚本中可能对于数据请求的类型做了限制,只接受post类型的数据提交。
(5) 构造post类型的html页面
这里分析给大家一个我也是刚刚学习到一个使用burpsuite直接构造csrf表单poc的方法。我们直接右击数据包截断页面,选择“Engagement tools”-“Generate CSRF PoC”,即可获取一个csrf的表单poc。
(6) 构造csrf html表单验证
随后我们将获取的表单内容复制到一个csrf.html文档中保存,并将此csrf.html发布到站点中(这里我就直接将poc房子lvye.com站点主目录中),随后就是想办法通过社工的方式诱使管理员访问此恶意页面,触发管理添加的操作。(当然我们这里只是简单的给大家演示了利用过程,实际的社工内容是怎样的,大家各自打开脑洞吧…)具体漏洞利用过程,基本演示如下。
4、CSRF 漏洞防护
其实现在有关CSRF漏洞防护已经是比较成熟了,其主要防护的思路就是需要在进行后台数据修改操作的过程中,添加对当前用户身份的有效验证措施,而不能仅限于cookie的识别,这里简单的罗列了下防护措施如下。
(1) 来源校验
使用http请求头中referer来源,对客户端源进行身份校验,此方法早期使用比较多,但是仍然容易被绕过,所以这里并不建议使用。
(2) 用户token 校验
添加基于当前用户身份的有效tokens随机验证机制,即在向后端提交数据操作请求时,添加基于当前用户的随机token校验值,此种校验方法当前使用比较多;
(3)当前用户密码验证
在修改关键信息时,要钱当前用户输入其自身的密码,以验证当前用户身份的真伪,防止未授权的恶意操作;
(4)添加验证机制
在请求数据的提交前,需填写验证码信息提交,以增加对用户来源的有效验证,防止恶意未授权的操作产生。
本文转自安全课