根据提示点击进入一个账号修改信息抓包

抓包submit

右键复制网址

新建标签页访问此网址

依旧修改信息抓包

构造CRSF POC

双击访问

理解思路：

• 你登录 allen 账号，手动在修改密码页把密码改成123456，抓包拿到这个请求；

• 用抓包内容生成 POC，把 POC 里的新密码改成654321；

• 打开这个 POC 的 HTML 文件，Kobe 的密码就被自动改成654321；

• 你回到靶场的修改密码页面（此时还没退出登录），输入原密码654321，新密码改回123456，提交后密码就恢复了；

• 哪怕你退出了登录，只要知道654321这个密码，重新登录后依然能改密码

实际场景：

攻击逻辑：

1. 你（攻击者）先通过抓包 / 分析，拿到 “修改密码” 的请求格式（比如http://靶场地址/csrf_edit.php?userid=1&newpwd=黑客密码）；
2. 你把这个请求做成 POC（比如一个 HTML 文件，里面用）；
3. 你把这个 POC 通过钓鱼链接、邮件等发给受害者（比如 Kobe）；
4. 只要受害者此时已经登录了靶场 / 网站（浏览器里有有效的登录 Cookie），哪怕他正在看网站的首页、个人中心，甚至只是点开你的钓鱼链接（没打开任何修改页面），只要浏览器加载了这个 POC，就会自动发送 “修改密码” 的请求；
5. 服务器收到请求后，因为 Cookie 有效，会认为是受害者本人的操作，直接把密码改成你预设的 “黑客密码”—— 受害者全程可能毫无察觉，根本不用碰修改信息的页面。
6. CSRF 能改什么，完全看你抓的是什么包

• 你抓的是 修改密码的请求 → 生成的 POC 就 只改密码
• 你抓的是 修改用户名的请求 → POC 就 只改用户名
• 你抓的是 发帖子 / 删帖 / 转账 → POC 就 只做这件事

Cookie 是用户登录网站后，服务器发给浏览器的 “身份凭证”，网站靠它识别 “你是谁”。但 CSRF 和 XSS 利用 Cookie 的方式、目的、主动权完全不同：

表格

维度	CSRF（跨站请求伪造）	XSS（跨站脚本攻击）
核心逻辑	「借你的手办事」：盗用你的登录态（Cookie），伪造你发起的合法请求	「钻到你口袋里偷东西」：往目标网站注入恶意脚本，脚本在受害者浏览器里执行，直接获取 / 操控你的数据
是否需要注入代码	不需要，只需要构造恶意请求链接 / HTML（POC）	必须往目标网站注入恶意脚本（JS 为主）
利用 Cookie 的方式	浏览器自动携带 Cookie 发送请求，攻击者 看不到、拿不到 Cookie ，只能 “借” 它用	脚本直接读取 Cookie（比如 document.cookie ），攻击者能 拿到 Cookie 明文 ，甚至能冒充你登录
受害者状态要求	受害者必须已登录目标网站（Cookie 有效），但不需要在特定页面	只要受害者访问了注入恶意脚本的页面，不管是否登录（登录后危害更大）
攻击结果	只能触发预设的操作（改密码、改信息、转账），无法获取信息	可获取 Cookie、账号密码、输入的内容，甚至操控摄像头 / 键盘，危害更全面
主动权	攻击者只能 “预设操作”，无法实时获取反馈（比如不知道改密码是否成功）	攻击者能实时拿到数据，甚至远程操控受害者浏览器

GET 和 POST 是 HTTP 的两种请求方式，CSRF 利用这两种方式的核心逻辑没变（都是借受害者的登录态发请求），

度	GET 型 CSRF	POST 型 CSRF
参数传输方式	参数直接拼在 URL 里（比如 ?newpwd=123456 ）	参数藏在请求体里（URL 看不到，比如 newpwd=123456 在 Body 里）
POC 构造难度	极简单：一行代码就能实现（比如 / =）也可以直接复制网址只要能发送get请求都可以	稍复杂：需要用表单自动提交（纯静态 HTML 就能做）
攻击隐蔽性	极高：URL 可直接当链接，点一下就触发	较高：需要加载 HTML 页面触发表单提交，略麻烦但依然隐蔽
浏览器限制	有长度限制（URL 一般最多 2048 字符）	无长度限制，可传更多参数
防御难度	相对容易被忽视（URL 参数易被伪造）	稍难（但仅靠请求方式防御没用）

• POST 型抓包 → 构造表单 → 自动提交（不能直接访问 URL）

token作用：CSRF Token 就是一个只有当前页面才有的随机暗号，用来证明这是用户本人操作，不是第三方伪造的请求。

解题步骤：

• 识别 Token 位置在抓包的 HTTP 请求中，找到了 token参数，它就是服务器用来防御 CSRF 的令牌。

• 安装 Token 追踪插件在 Burp Suite 的 “扩展”（Extender）模块中，从 BApp Store 安装了 CSRF Token Tracker 插件。这个插件的作用是自动从响应中提取新的 Token，并在后续请求中自动替换，解决了 “Token 一次性” 的问题。

• 配置重放模块（Repeater）将抓到的修改信息请求发送到重放模块，并开启了 “跟随重定向”（Follow redirects）等设置，确保在测试时能完整模拟用户的操作流程，包括服务器的重定向响应。

boy改为bbbb

原理：

通过插件自动模拟 “打开修改页面 → 提取最新 Token → 替换到请求中” 的流程，让服务器误以为是合法用户操作，从而绕过 CSRF Token 防护。

1. 你（受害者）打开修改页面，服务器给你一个 一次性 Token（Token1）。
2. 你提交一次修改，Token1 就被消耗掉，服务器生成新的 Token2，给下一次操作用。
3. 如果你（攻击者）想伪造请求，你手里只有抓包时的旧 Token1，这个 Token1 已经失效了，服务器不认。

这是我们自己在网页里面测试，跟实际环境不一样 实际环境还是需要 XSS 才能拿到 token。