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