Pikachu靶场实战：反射型XSS(POST)通关详解与抓包利用-代码聚汇网

Pikachu靶场实战：反射型XSS(POST)通关详解与抓包利用

孙晓岸·2026-08-31·阅读 22 GEO检测（免费）

反射型XSSPikachu靶场POST请求

|难度：普通|阅读约 25 分钟

刚接触pikachu靶场时，我其实有点轻敌。反射型XSS嘛，不就是输入一段script标签然后等着弹窗？结果真正卡住我的不是payload，而是POST这三个字母。以前练反射型XSS，我习惯在URL里改参数，因为GET型的数据都在地址栏，改完回车就能看到效果。但pikachu里这道“反射型XSS（post）”考点不一样：数据不在地址栏，而在请求体里，浏览器默认不给你编辑请求体的入口。为了通关，我被迫去抓包、去理解POST请求的结构、去复现一条从前端页面到Burp再到服务端返回的完整链路。这篇就把我从零搭环境到成功弹出alert(1)的全过程写下来，适合刚入门Web安全、正在刷pikachu靶场、或者面试前突击XSS知识点的朋友。

1. 为什么先把反射型XSS(POST)单拎出来练

1.1 靶场里这个题目到底在考什么

pikachu是一个运行在本地的PHP漏洞练习平台，集成了XSS、SQL注入、CSRF、SSRF、RCE这类常见Web漏洞类型。它的“反射型XSS（post）”位于XSS模块下，和另一个“反射型XSS（get）”是对应关系。这个名字已经告诉了你三件事：漏洞类型是反射型XSS，数据传输方式是POST，练习目的是观察输入怎么被反射并执行。如果你能在本地把这个实验完整跑通，对HTTP协议中request body、响应内容以及浏览器解析脚本的关系，会建立非常直观的感觉。

为什么我建议学习顺序里不要跳过这一题？因为GET型太容易形成路径依赖。你只要在URL后加?message=<script>alert(1)</script>就能复现，很多新手会误以为反射型XSS就是“在地址栏拼参数”。POST型会把你的视线逼到请求体上，逼你去理解一个HTTP事务的全貌。这就引出一个核心问题：你以为你在测XSS，其实你是在练HTTP协议的基础功。

1.2 反射型XSS的原理，三句话就能讲清楚

反射型XSS的链路可以压缩成三句话。第一，服务端没有对用户输入做严格校验或输出编码；第二，用户提交的内容被原样拼进了返回的HTML；第三，浏览器解析这段HTML时执行了攻击者塞进来的脚本。数据是“反射”回来的，不像存储型那样写进数据库，所以每次触发都需要受害者构造或提交一个特定请求。

POST只是传输载体的一个选择。你把<script>alert(1)</script>放在URL参数里，就是GET型；把它放在请求体里，就是POST型。漏洞根源完全一致，但利用姿势完全不同。尤其要注意：POST型不能简单做成一个链接丢给受害者点击，得配合页面自动提交，比如用一个HTML表单。下面这段报文，就是你提交恶意输入时Burp里看到的样子：

http复制POST /pikachu/vul/xss/xss_post.php HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded

message=%3Cscript%3Ealert(1)%3C%2Fscript%3E&submit=submit

后面所有操作，本质上都是在改body里的message字段。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 环境准备阶段最容易翻车的几个点

2.1 pikachu靶场下载和运行环境的选择

pikachu是PHP写的，所以需要一个LAMP或者Windows下的集成环境。源码一般从官方仓库下载压缩包，解压后放到Web根目录。我自己试下来，用phpstudy的Apache+PHP 7.x+MySQL 5.7最省事，因为老教程里常见的PHP 5.x虽然能跑，但某些函数在新版本里已经有兼容性问题。如果你下载的版本比较新，务必确认PHP版本不低于7.0，否则数据库连接和部分错误提示可能不按预期走。

操作流程大致是这样：

下载并解压pikachu源码，放到Web根目录
启动Apache和MySQL
修改源码里的inc/config.inc.php，把数据库账号密码改成你本机的
浏览器访问http://127.0.0.1/pikachu/，按页面提示初始化数据库
初始化完成后进入XSS模块，找到“反射型XSS（post）”

这里有个小坑：很多人解压完直接访问，页面提示数据库连不上，就以为是源码坏了。其实是config.inc.php里的默认密码和你本机MySQL不一致。改一下就行，不用怀疑人生。另外，如果你本机的80端口已经被占用，记得把Apache的监听端口改掉，或者用nginx反代，不然靶场怎么都起不来。

2.2 浏览器和抓包工具必须提前配合好

POST型反射XSS的通关利器是Burp Suite。这在我的工作流里不是可选项，而是必选项，因为你需要修改请求体。Burp的基础配置虽然老生常谈，但每次带新人都会发现有人卡在这里：浏览器走127.0.0.1:8080代理，然后在Proxy->Options里确认监听端口已经打开，再访问任意HTTP页面，看Burp里能不能看到流量。如果是HTTPS站点，还要安装CA证书。虽然pikachu靶场默认HTTP，但养成装证书的习惯，能省掉以后调试其他靶场时的很多麻烦。

我实操中踩过一个坑：忘记关系统代理或者浏览器扩展的代理设置，导致Burp能抓到包但页面加载缓慢，最后发现是代理链叠加了。更常见的是IE内核浏览器对代理支持差，建议直接用Chrome加Proxy SwitchyOmega，或者Firefox的FoxyProxy。Burp的界面可以不用全懂，但Proxy拦截、Repeater、History这三个模块，今天必须用熟。

2.3 靶场初始化成功后怎么确认漏洞点

初始化完成后，进入反射型XSS（post）页面，会看到一个文本框和一个Submit按钮。看起来其貌不扬，但我建议你先在Burp里确认一次正常提交。输入test123，点提交，看返回页面里是否出现了test123。如果连这一步都看不到，说明请求没到靶场，或者代理没配好。这时候不要急着上payload，先把基础链路打通。

判断标准很简单：Burp的HTTP history里能找到一个POST /pikachu/vul/xss/xss_post.php记录，响应里能看到你输入的标记字符串。只要这两点确认了，后面就是纯payload测试。

3. 一步步把POST请求改造成可执行payload

3.1 正常提交一次，把数据流画出来

输入test123并提交后，在Burp的HTTP history里找到那条POST记录，查看请求报文：

http复制POST /pikachu/vul/xss/xss_post.php HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

message=test123&submit=submit

响应报文里有一段：

html复制<p class="notice">test123, what do you see?</p>

这就是最典型的反射点：输入值被拼到了标签里直接返回。这里的参数名是message，后面所有payload都塞给它。你现在应该在脑子里画一条线：文本框的值 -> 表单POST -> body里的message -> PHP用$_POST['message']取值 -> 拼到HTML响应中 -> 浏览器渲染。这条线里任何一个环节断掉，XSS都不成立。

3.2 在Burp中拦截并替换message为payload

打开Proxy的Intercept，回到页面输入一个普通值，点击提交。Burp拦截到请求后，在body里把message=test123改成message=<script>alert(1)</script>，然后Forward。回到浏览器，弹窗就会出现了。

这里有几个操作细节，新手经常栽跟头。第一，如果改成<script>alert(1)</script>没弹窗，先看是不是浏览器自带的XSS过滤器拦截了。Chrome在某些情况下会阻止反射型XSS，页面会显示一个警告提示。这种情况下可以换一个payload：<img src=x onerror=alert(1)>，这个在很多过滤环境里更稳，因为它不依赖script标签。第二，如果你改了请求体但长度变了，一定要确认Burp的Update Content-Length是开启的，否则服务器收到的Content-Length和实际body长度对不上，请求会被判定为异常，甚至直接reset连接。

3.3 用Repeater和Python做批量验证

弹窗成功后，大部分人就会收工。但我建议你用Repeater把几组常用payload全部过一遍，一方面练手，一方面对比响应差异。把请求发送到Repeater，每次只改message的值，观察响应里是原样回显、被转义、还是被截断。你想验证多少种姿势，就发多少次。

也可以写一段简单的Python脚本：

python复制import requests

url = "http://127.0.0.1/pikachu/vul/xss/xss_post.php"
payload = {"message": "<script>alert(1)</script>", "submit": "submit"}

r = requests.post(url, data=payload)
print(r.text)

requests.post的data参数默认会按表单格式提交，模拟的就是浏览器里那个POST请求。这个脚本的价值不是让你偷懒，而是帮你建立“自动化测试”的意识，后面测SQL注入、CSRF、SSRF时同样能复用。我自己还会加一个循环，把payload列表轮流塞进去，批量看响应里是否出现payload原文，这个后面细说。

3.4 确认是“反射执行”而不是“存储”

很多人打完弹窗就结束了，但其实你可以再提高一步：换一个只存在于当前请求的随机字符串，提交后刷新页面，看它是否消失。如果刷新后找不到了，说明是反射型；如果刷新后还在，说明数据被存进数据库或Session里了，那就是存储型XSS的范畴。这个细节能帮你区分反射型和存储型，面试或者写报告时经常要用到。

4. POST型反射XSS和GET型差在哪，不只是地址栏

4.1 两种方式的复现门槛完全不同

GET型反射XSS，整个利用链就是一个URL。你把构造好的链接发出去，受害者点击，脚本就执行了，前提是浏览器没有拦截。POST型不一样，请求数据在body里，你没法直接用地址栏构造。如果要在真实场景里利用POST型反射XSS，通常需要搭一个恶意页面，通过JavaScript自动提交一个表单到目标地址，把payload作为参数带过去。

这个差异导致很多入门教程把GET型写得很细，POST型一笔带过。但POST型的利用思路更接近真实攻击中的一个重要场景：诱导用户访问恶意页面，页面悄悄向目标站点发起一个带payload的POST请求。理解这个链路，比单纯会弹窗有用得多。你可以尝试本地写一个HTML文件：

html复制<html>
<body>
<form id="f" method="post" action="http://127.0.0.1/pikachu/vul/xss/xss_post.php">
    <input type="hidden" name="message" value='<script>alert(1)</script>'>
    <input type="hidden" name="submit" value="submit">
</form>
<script>
    document.getElementById('f').submit();
</script>
</body>
</html>

打开这个页面，浏览器会立刻向靶场发起POST请求，如果一切正常，同样会弹窗。这个例子只在本地靶场环境验证，不要拿去对非授权目标做测试。

4.2 服务端和浏览器对POST请求的处理差异

有些防护组件会默认过滤URL参数，但对POST请求体过滤得不彻底，或者反过来。这就会出现“GET型测不出，POST型却能打”的情况，反之亦然。所以评估一个站点的XSS风险时，两种方法都不能漏。我自己测试时会准备一份通用payload清单，先测GET参数，再测POST参数，每个字段都单独过一遍。

4.3 手动改包的能力要求更高

POST型要求你会看Content-Type、Content-Length、表单编码方式。如果Content-Type是application/x-www-form-urlencoded，body里的特殊字符要URL编码，Burp会自动处理大部分，但手写Python时记得用urllib.parse.urlencode。如果接口接收的是JSON格式的POST，payload就要放到JSON字段里，测试思路又要变。我曾经在本地调试一个API时，直接把表单payload塞进JSON字段，结果服务端没有解析，我还以为是触发WAF了，白折腾了半天。先搞清楚后端解析的是表单还是JSON，能省下大量时间。

5. 通关过程中我踩过的坑和定位思路

5.1 弹窗没出现：第一反应不是换payload，而是看包

当你提交payload后没有任何反应，比较高效的排查顺序是：先看Burp里请求是否发出、响应里有没有报错；再看响应源码里你的payload是原样出现在HTML中，还是被转义成<script>；如果被转义，说明服务端有输出编码，换变形payload可能突破；如果是原样出现但浏览器没执行，大概率是浏览器拦截了，或者页面结构导致脚本没有进入可执行上下文。

这个顺序比盲目换payload有效得多。很多新手一上来就疯狂换姿势，结果问题出在代理没配好，请求根本没到靶场。抓包是第一步，永远不要跳过。

5.2 连接被重置：排查Connection reset executing post

本地练习时，可能会遇到“Connection reset executing post”这类报错。常见原因有好几个：请求头带了奇怪的值被服务端拒绝；目标服务崩溃；Apache或PHP进程锁死；代理端口被占用。我的处理习惯是：先关掉Burp的拦截，用浏览器直接再提交一次，看是不是靶场本身挂了；然后看Apache的错误日志，路径一般在phpstudy的Extensions/Apache2.4.39/logs，或者Linux下的/var/log/apache2/error.log；最后把POST请求在Burp Repeater里原样发一遍，排除脚本问题。很多时候是Content-Length没更新导致的，改完就会恢复正常。

5.3 Chrome的XSS过滤器误伤

Chrome会把某些反射型XSS自动拦截，并显示“网页已被屏蔽”的提示。如果你在本地靶场测试，不想被它干扰，可以在启动Chrome时加--disable-xss-auditor参数，或者直接用Firefox。但要注意：真实环境中拦截器的存在也是必须考虑的因素，不能默认所有用户都不会被拦截。靶场里你可以关掉它方便验证，做真实评估时反而要记录拦截器的影响。

5.4 编码和长度限制

POST型请求体比URL参数能容纳更多内容，理论长度上限更大，但具体靶场代码可能限制字段长度，maxlength属性或者服务端截断都可能导致payload不完整。如果payload被截断，先看页面源码里输出到了哪个位置，再调整payload长度。另外要留意URL编码：表单编码里空格会变成+，这个正常；但如果换成JSON格式，空格还是要按JSON规则处理。不要想当然地把一套编码规则套到所有接口上。

5.5 忘记清Cookie导致Session混乱

靶场有时候会把用户会话和测试记录写进Cookie或Session，反复实验后可能出现页面显示异常。我的做法是：每测完一个payload，用无痕窗口或清一次Cookie，刷新页面，避免旧状态干扰响应判断。这个习惯看着琐碎，但能帮你少做很多无用功。

6. 练完这一题，我是怎么沉淀测试模板的

6.1 把POST型XSS的测试步骤写成checklist

我每次遇到一个新靶场或者授权测试的目标，不会凭感觉乱测，而是按固定模板来。这套流程是在pikachu上形成的，后面放到其他环境也完全通用：

收集目标页面所有POST接口和请求参数
对每个参数单独提交一个标记串，比如pikachu_test_123
在响应里搜这个标记串，记录哪些字段被反射
对被反射的字段逐一替换成XSS payload
记录payload是否被执行，响应是否转义
如果被转义，尝试大小写、标签嵌套、事件属性、编码等变形
最后写清楚利用条件和影响范围

这套流程帮我避免过“测了半天发现唯一漏洞点被忽略了”的尴尬。反射型XSS的测试从表面看是随机的，但落到实际执行时，完全可以做得像一个自动化脚本一样有顺序。

6.2 反射型XSS的防护和危害，要一起复盘

靶场练习结束后，别忘了翻一翻服务端代码。pikachu的这个题目在PHP文件里故意没有做过滤，所以$_POST['message']直接进了HTML输出。真正的开发环境里，至少要做到输入侧校验白名单，输出侧根据上下文做HTML实体编码。你可以自己改一改源码，比如加上htmlspecialchars($message, ENT_QUOTES, 'UTF-8')，再重新提交payload，看看弹窗是不是消失了。亲手实践一次“修复漏洞”，比单纯打靶印象深得多。

危害方面，反射型XSS可以窃取会话Cookie、钓鱼、伪造请求。但我要强调：这些危害的验证必须在授权范围内进行，最好就在自己的靶场里。不要因为学会了POST型XSS，就跑到外网去试探，那是非常糟糕的习惯，也会把自己置于完全不必要的风险里。

6.3 后续还能往哪个方向深挖

如果POST型反射XSS已经熟练了，可以继续在同一套靶场里尝试：存储型XSS、DOM型XSS、XSS获取Cookie并模拟登录、加上HttpOnly标志后还能不能读Cookie、Content Security Policy能挡住多少种payload。这些方向我后面会单独写。

最后分享一点个人体会：我见过很多入门者打靶时只是照着教程点击弹窗，从不停下来看请求报文。而这道POST型反射XSS，恰恰是逼迫你打开Burp看请求体的题目。当你真的看懂了那一小段message=xxx&submit=submit，后续学SQL注入、CSRF、SSRF都会顺畅很多，因为HTTP协议是你绕不开的起点。把这个基础打好，比多刷十个靶场都值得。