CRSF跨站请求伪造原理（大学生视角） - 详解

前言

笔者先把web写完吧，最近在学习更多的东西，web写完就会有下一步动作，RCE，XXE,CRSF都会更新的。

准备

笔者依然在小皮面板的apache，PHP，MySQL的集成环境下搭这环境，靶场就是著名的pikachu。

操作

先说说什么是csrf

笔者就按照自己的理解讲了，就是当我们用户登录一个网站时，登陆成功后服务端会给我们客户端返回一个cookie，那么什么是cookie呢，其实你就把cookie当作是自己的一个身份，我们每次对该网站进行操作时，都会在请求包带上我们本地存着的cookie，借此来表明自己的身份，比如说我是小明，我登录了A网站，A网站就会给我一个小明的cookie，以后我在该网站进行任何操作都会带上小明的cookie，表面我在以小明的身份干这件事，以后进行的运行都是对于小明的。

这时候又有一个人出现了——小红，他想偷偷的改掉小明的账号密码改成666666，所以小红制作了一个可以修改密码的请求，然后把这个请求链接（get方式）发给了小明，然后小明在登录着A网站的情况下（小明本地还存在对于A网站的cookie），抱着好奇心而点击了小红所发的链接（这个链接的效果就是修改密码为666666），小明就会对A网站发出要把密码改为666666的请求，并且带着的是自己的cookie，因为带着小明自己的cookie，因此这个请求就会把小明自己在不知情的情况下密码修改为666666，从而受到一个CSRF攻击。

冒充了用户的cookie。就是于是相比于XSS，CRSF并没有盗取用户的cookie，而

pikachu

get类型

首先，打开我们的pikachu靶场，从左侧导航栏找到CSRFget类型，找到点一下提示，看可供我们登录的账号。

这里我先用lili来登录，然后点击修改个人信息。

大家随便修改一下他的几个信息。

我这里把性别改为1，手机改为1，然后用我们的burp代理抓包。

看请求包，把大家请求的路径先进行复制（请求体标蓝的部分）。

Google，访问我们的pikachu靶场。然后用另一个账号登录，这里我用vince。就是然后打开另一个浏览器，我这里用的

然后把大家复制好的路径放在pikachu域名后面，点击回车，可能看到Vince的信息被我们修改成功

那结果为什么会这样呢，还是我开头举的那个例子，这里因为Vince账号已经被我们的Google浏览器所登录，Google浏览器本地保存了Vince的cookie，故而当我们以Vince的身份发起修改密码的请求时，自然是修改Vince的信息。

post类型

我们点击crsf(post)，依然是在edge与Google上分别登录lili和Vince，接着还是在lili修改信息的地方抓包，这里我们把性别和手机都改成2。

然后我们在请求包的地方右键，找到Engagement tools，然后点击Generate CSRF PoC生成我们恶意的form表单。

然后我们复制一下burp给我们生成的form表单，然后新建一个html文件，然后在Google浏览器中打开。

默认生成手动提交的表单）。就是点击提交请求（其实是有自动提交的表单，不过burp还

大家可以发现Vince的性别和手机就全变成2了。

token类型

token是什么，token其实也是对身份进行校验的一个随机字符串，服务端会给你一个token，然后你在本网站再进行请求时会带上这个token，如果你的token与服务器中存储的token不一样时，这个请求就会报401或者403，大家的token每次请求都会改变。

在pikachu靶场中，他每次请求token都会更改，所以这里我们需要启用到一个burp插件CSRF Token tracker这个插件可能追踪我们的token，但是你得先进行一些调整。

token，所以我们在name输入token，然后把我们所抓到的修改数据的请求包的token值放到value里面，我们就许可成功追踪token了。就是这里我的pikachu靶场是在本地搭建的所以host输入127.0.0.1，然后我们追踪的内容

此时我们把数据包扔到repeater里面，把sex改成3，把token复制到我们CSRF Token Tracker的value里面，然后连续点击两次send，看响应包的render浏览器渲染发现我们就可以成功修改了。

为什么要点两次 Send

1. 第一次 Send：

   • 目的是让 Burp自动抓取最新的 token

   • Tracer 先从响应中提取 token，更新到请求中

   • 因为修改前的请求 token 可能已经失效或者空，于是第一次发送只是让 Burp 获取并替换 token

2. 第二次 Send：

   • 这次请求中已经包含了正确的最新 token

   • 服务器收到请求后验证 token → 请求修改成功

写在后面

其实笔者对cookie，token，session ID的各种验证机制也是一知半解，都是按自己理解来的，欢迎师傅们批评指正！