简介

Pikachu靶场中的CSRF漏洞环节里面有一关CSRF TOKEN，这个关卡和其余关卡稍微有点不一样，因为表单里面存在一个刷新就会变化的token，那么这个token是否能绕过呢？接下来我们来仔细分析分析

实战过程

简单尝试

先利用任意一个用户登录进去，然后进入修改数据页面：

提交，利用burp抓包：

然后生成POC：


以相同浏览器打开测试：

这个地方改不了的原因是因为带有token参数。接下来简单讲讲token原理。

Token原理

每次访问页面的时候，在后端生成一个token然后存放在SESSION中。
并且将token渲染到表单中。
然后提交表单的时候，就会携带这个token，后端接受到这个token的时候和session中的token进行对比
如果一致：请求合法
如果不一致：请求失效
简单看一下代码：
生成token的代码：

// 开启sessionsession_start();// 准备生成token$token = md5(rand(1,10000));// 放到SESSION中$_SESSION['token'] = $token;

验证token的代码：

header("content-type:text/html;charset=utf-8");// 接受数据// 获取session中的tokensession_start();$s_token = $_SESSION['token'];// 获取表单中的token$token = $_POST['token'];// 判断tokenif ($token != $s_token){// 防止token重用， 判断token完了之后，token替换$_SESSION['token'] = md5(rand(1,10000));echo "请求不合法!";die;}// 防止token重用， 判断token完了之后，token替换$_SESSION['token'] = md5(rand(1,10000));echo "请求合法！";

所以token必须要一致才能提交成功，否则就会失败。

利用burp插件来绕过

先安装插件：

按照步骤点击安装即可。

然后设置插件：

我们抓一个包：


点击Go发现数据已经发生变化：

这个时候要点击一下Follow redirection

看插件：

再看页面：

这个地方大概的原理应该是插件通过异步去先一步去获取token的值，然后将请求的token值给替换了。
但是这个地方仅仅做实验应该是可以的，真实场景实用性不强。
后续再讨论真实场景的token绕过。

来源地址：https://blog.csdn.net/miraclehw/article/details/129411937