简介：Pikachu 靶场资源包（pikachu-master.zip）是一套面向网络安全学习者的综合漏洞演练环境，适合从入门到进阶的安全爱好者、渗透测试人员及高校学生使用，可用于在可控环境中理解并实践常见 Web 漏洞的攻防原理。包体共 284 个文件，约 3.52MB，以 PHP 源码、JavaScript 脚本、CSS 样式和 PNG/JPG 图片为主，并包含 Dockerfile、配置文件与说明文档，便于快速搭建和本地部署。资源完整覆盖 SQL 注入、XSS 跨站脚本、CSRF 跨站请求伪造、文件包含、命令注入、越权与权限提升等典型漏洞模块，每个模块都配有实际页面和练习场景，配合源码阅读与日志观察，可深入掌握漏洞成因、利用手法和防御要点。已有 1548 人学习下载，适合通过手动复现与代码审计相结合的方式，系统提升 Web 安全检测与防护能力。 pikachu-master.zip，这个文件名乍一看像个游戏资源包，但老手一眼就认出来——这是Web安全圈流传很广的Pikachu漏洞测试平台的源码压缩包。它是一个专门用来练习Web漏洞挖掘与利用的本地靶场，把SQL注入、XSS、CSRF、文件上传、反序列化等经典漏洞场景全部做成了图形化页面，装上就能开打。
很多人学Web安全卡在第一步：理论书翻了三章，Burp Suite装了，但找不到地方练手。Pikachu解决的就是这个痛点——你不需要搭建复杂的漏洞环境，解压、配置数据库、启动服务，一个能练手的靶场就绪了。这套东西特别适合两类人：一类是刚入门Web安全、想系统刷一遍漏洞类型的新手；另一类是准备护网、面试，需要短期找回手感的从业者。这篇文章我就从搭建开始，把核心漏洞模块的通关思路和路上踩过的坑一次讲清楚。
1. Pikachu是个什么项目？——先搞清它的设计思路
1.1 为什么叫Pikachu，它和DVWA有什么不同
Pikachu是国内安全圈一个开源Web漏洞靶场项目，名字取自《精灵宝可梦》里的皮卡丘，原因很简单：项目作者希望把漏洞学习做得像收集宝可梦一样有趣。相比同类的DVWA（Damn Vulnerable Web Application），Pikachu的界面更贴近国内开发者的使用习惯，漏洞场景也更多样。
DVWA的定位是"最小化漏洞演示"，一个漏洞一个页面，功能极简。而Pikachu更接近真实业务逻辑：比如SQL注入模块里分了数字型、字符型、搜索型、宽字节四种场景，XSS模块分了反射型、存储型、DOM型，每个场景都模拟了一个具体的业务页面，比如搜索框、留言板、个人信息修改。练的时候你会觉得是在对一个真实的网站做测试，而不是对着教学Demo发呆。
1.2 模块全景：这套靶场到底能练什么
我整理了一份Pikachu自带的漏洞模块清单，基本上覆盖了Web渗透测试的常见类型：
| 漏洞类型 | 涉及子场景 | 难度评价 |
|---|---|---|
| 暴力破解 | 基于表单、验证码绕过 | 入门友好 |
| XSS | 反射型、存储型、DOM型 | 入门友好 |
| CSRF | 修改信息、删除操作 | 中低难度 |
| SQL注入 | 数字型、字符型、搜索型、宽字节 | 由浅入深 |
| RCE | exec命令执行、代码注入 | 中高难度 |
| 文件包含 | 本地文件包含、远程文件包含 | 中高难度 |
| 文件上传 | 前端限制、MIME类型、扩展名黑名单 | 中高难度 |
| 越权 | 水平越权、垂直越权 | 中低难度 |
| 目录遍历 | 路径穿越读取文件 | 入门友好 |
| 反序列化 | PHP反序列化漏洞 | 高难度 |
| XXE | XML外部实体注入 | 高难度 |
| 敏感信息泄露 | 目录浏览、测试文件残留 | 入门友好 |
| URL重定向 | 跳转绕过 | 入门友好 |
我自己的经验是：不需要按顺序刷，但建议先过一遍SQL注入和XSS，这两个模块是Web安全的基础，后面理解RCE和反序列化会顺很多。
2. 本地搭建一条龙：从zip包到能打开的靶场
2.1 环境准备：Windows最简单，Linux也不难
Pikachu是基于PHP+MySQL的Web应用，所以需要一个能跑PHP的运行环境。最省事的方案是装phpStudy（现在叫小皮面板），它把Apache、Nginx、PHP、MySQL打包在一起，一键启动。
如果你不喜欢集成环境，也可以手动装：Apache/Nginx任意一个、PHP 5.6或7.x、MySQL 5.x，这三件套跑起来就行。不过我给新手的建议还是phpStudy，省去配置虚拟主机和PHP-FPM的麻烦，Windows和macOS都支持。实测下来，PHP 5.6和7.0对Pikachu的兼容性最好，PHP 8.x可能有些旧函数被移除，后面会说到这个坑。
2.2 部署步骤：解压、放目录、配数据库
拿到pikachu-master.zip之后，部署流程分三步走：
解压压缩包，把里面的
pikachu-master文件夹整个复制到Web根目录。用phpStudy的话，就是WWW目录下，一般是C:\phpstudy_pro\WWW\。重命名建议去掉-master后缀，方便访问，比如改成pikachu。打开
inc目录下的config.inc.php，修改数据库连接信息。默认配置是针对本地的，如果你用的是phpStudy默认的MySQL，账号密码是root/root，那就不用改。如果改了密码，把下面这三行改成你自己的：
define('DB_HOST', '127.0.0.1'); define('DB_USER', 'root'); define('DB_PASS', 'root'); define('DB_NAME', 'pikachu');- 启动Apache和MySQL服务，浏览器访问
http://localhost/pikachu/。如果没有报错且出现安装引导页，点击"初始化"或"安装"按钮，系统会自动创建pikachu数据库并导入数据表。
整个过程其实不超过五分钟。
2.3 安装时的几个经典报错
我第一次装的时候就遇到一个问题：页面提示数据库连接失败。排查思路很简单——先确认MySQL启动了，再看config.inc.php里的密码对不对，最后确认MySQL端口是不是3306。如果用phpStudy改了MySQL端口，还要同步该文件里的端口配置。
另一个典型问题是访问http://localhost/pikachu/install.php时白屏。多数情况下是PHP版本太高导致的，把phpStudy切回PHP 7.0或5.6就好了。还有一个容易被忽略的点：PHP 8.0后mysql_*系列函数被移除了，如果Pikachu的旧代码还在用这些函数，开PHP 8会直接报Fatal Error。
3. 六大核心漏洞模块通关解析
3.1 SQL注入：数字型、字符型、搜索型，一个都不许跳过
SQL注入是Web安全里最经典也是最基础的漏洞。Pikachu的SQL注入模块分为数字型、字符型、搜索型、宽字节，正好对应了实际开发中常见的几种写法错误。
数字型注入的原理很简单：后台直接用字符串拼接的方式把参数拼到SQL语句里，而参数值是数字类型，没有用引号包裹。比如后台可能是这样写的：
SELECT * FROM users WHERE id = $id;当你提交id=1时，SQL是WHERE id = 1，正常查询。但要是在参数后面拼上and 1=1，SQL变成WHERE id = 1 and 1=1，永远为真，返回所有数据。而提交and 1=2时，SQL变成WHERE id = 1 and 1=2，恒为假，页面就没有数据。通过这两种返回结果的差异，就能判断出注入点存在。
判断出是数字型注入后，下一步就是爆字段数、找显示位、爆库名表名字段名。经典payload如下：
id=1 order by 2 id=1 and 1=2 union select 1,2,3 id=1 and 1=2 union select 1,database(),version()字符型注入的区别在于后台SQL用了单引号包裹参数，比如WHERE name = '$name'。所以你需要先闭合引号，再拼接自己的payload，典型操作是必须把引号闭合完整。最经典的判断方法是用name=1' and '1'='1，如果页面正常，说明注入点成立。这个细节是新手最常卡住的地方：数字型注入不用管引号，字符型注入必须关注引号的闭合。
搜索型注入本质上是字符型的一种变体，后台用了LIKE '%keyword%'模糊查询。同样的闭合思路，payload要写成keyword=%' and 1=1 and '%'='这种形式，俗称"闭合并绕过百分号"。这部分建议你在Pikachu上反复练几遍，练到看见引号就知道怎么闭合的程度。
宽字节注入稍微特殊一点，它是因为数据库编码用了GBK，而PHP对特殊字符转义时只加了一个反斜杠，导致反斜杠被GBK编码"吃"掉。Pikachu这个场景设计得很有代表性，遇到需要用%df'这种构造方式去闭合的题目，基本就是宽字节注入没跑了。
3.2 XSS三兄弟：反射、存储、DOM，原理和利用大不同
XSS（跨站脚本攻击）的本质是把恶意脚本注入到页面中被执行。Pikachu把XSS分成了反射型、存储型、DOM型，三种类型看起来都是弹个弹窗，但背后的原理和危害完全不一样。
反射型XSS是最"直白"的一种：恶意Payload通过URL参数提交给服务器，服务器把参数内容原样拼进返回的HTML里。比如Pikachu的反射型XSS页面，输入框会把你填的内容写入URL中的message参数，后台返回的页面里直接用$_GET['message']拼到HTML输出。你提交<script>alert(1)</script>，页面就会弹出弹窗。这类XSS的核心特点是"一次性"，Payload跟随着URL走，所以常被用来构造钓鱼链接。
存储型XSS的危险性更大，因为它把Payload存到了数据库里，任何访问该页面的用户都会中招。Pikachu的存储型XSS场景是一个留言板，你在留言内容里写入恶意脚本，后台存入数据库，下一次刷新页面的时候脚本被重新加载执行。这种XSS在真实环境中会变成"蠕虫式攻击"——所有访问留言板的用户浏览器都会被劫持。
DOM型XSS跟前两者不同，它不经过服务器端，完全是前端JavaScript代码把不可信数据写进了DOM节点。Pikachu的DOM型XSS场景里，JavaScript会读取URL中的#号后内容，然后通过innerHTML写入页面。这种情况下，即使服务器做了过滤，只要前端代码存在这样的DOM写入操作，漏洞依然存在。
练Pikachu的XSS模块时，我的建议是别只停留在弹窗验证，多试试<svg onload=alert(1)>、<img src=x onerror=alert(1)>这类变体，理解不同标签触发时机。你会发现，真正到了实战中，payload是不是能打出来，取决于过滤规则到底滤掉了什么。
3.3 暴力破解与验证码机制的博弈
暴力破解模块也是Pikachu的重头戏。这一模块设计了四种场景：没有验证码的登录框、有客户端验证码的登录框、有服务端验证码的登录框、基于Token防重复提交的登录框。这四种场景覆盖了最常见的登录安全措施。
没有验证码的登录框是最容易打的，直接上Burp Suite抓包，发送到Intruder模块，把密码字段设置为变量，加载一个弱口令字典，开跑。用默认的admin用户名，弱密码字典两三分钟就能出一个结果。
有客户端验证码的场景就有意思了。这个验证码是前端JavaScript生成的，校验逻辑也在前端，也就是说服务端根本不验证验证码对不对。你抓包把验证码参数删掉或者随便填一个，居然就能正常登录。这种问题在真实环境里并不罕见，很多系统为了"用户体验"把验证码校验做在前端，等于没做。
有服务端验证码的场景就正经多了。验证码的值存在Session里，提交时需要带上正确的验证码才能继续。最基础的绕法是通过Burp的宏功能让每次请求都自动刷新验证码，或者用验证码识别插件做OCR。这个场景的练习重点不是"怎么绕过"，而是让你理解：只要服务端每次都校验验证码且过期时间设置合理，暴力破解的成本就会直线上升。
基于Token的登录框更接近现在的主流设计。每次请求页面时服务端都生成一个随机的Token并写进表单里，提交时必须带上正确的Token。如果你只提交用户名和密码，会提示Token无效。绕过思路是通过正则表达式从响应页面中提取Token，再拼进下一次请求里，Burp里正则提取加变量引用的方式可以搞定。
练这个模块最关键的收获是：别一上来就开跑，先抓包分析登录逻辑中哪里是薄弱点。验证码校验在前端还是服务端？Token是否可预测？是否有次数限制？这些思考方式，直接决定了你以后做接口安全测试的思维层级。
3.4 反序列化漏洞：入门难，但理解后威力巨大
PHP反序列化是Pikachu里难度较高的模块，很多初学者看到unserialize($_GET['data'])这种代码就懵。我尽量用大白话讲清楚。
序列化（serialize）是把对象转换成字符串以便存储或传输，反序列化（unserialize）则是把字符串还原成对象。这个机制本身没有问题，但如果反序列化的数据来自用户输入且没有被严格过滤，攻击者就可以构造一段"恶意字符串"，让程序反序列化出一个设计好的特殊对象。
Pikachu的反序列化模块给了你一段PHP源码：
class S{ var $test = "pikachu"; function __destruct(){ echo $this->test; } } $s = $_GET['data']; $unserialize = unserialize($s);这里的关键是__destruct()（析构函数），对象被销毁时自动执行。如果攻击者把$test属性改成<script>alert(1)</script>，反序列化后对象销毁时就会输出这段脚本。构造payload的方式是把一个类实例序列化后再URL编码：
$s = new S(); $s->test = "<script>alert(1)</script>"; echo serialize($s);这段脚本输出类似O:1:"S":1:{s:4:"test";s:19:"<script>alert(1)</script>";}，把这个字符串作为data参数提交，就能看到弹窗。
理解这个模块的核心不是背payload，而是理解反序列化会造成哪些魔术方法被执行。真实场景里PHP反序列化漏洞的利用链（POP链）非常复杂，这也是它在CTF和攻防演练中比较少见但一旦出现就是高分题的原因。Pikachu给你的是一个最简入口，先把对象属性注入的原理吃透，后续再学利用链构造会轻松很多。
4. 通关路上的高频问题与排查技巧
4.1 经典报错速查表
练靶场和真实项目一样，最烦的不是漏洞本身，而是环境报错。我从自己带新人的经验里整理了一份高频问题速查表：
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 安装页打不开 | PHP版本过高、扩展缺失 | 换PHP 5.6/7.0，开启php_openssl等扩展 |
| 数据库连接失败 | 密码错误、MySQL未启动、端口不对 | 核对config.inc.php，确认MySQL端口3306 |
| 页面中文乱码 | 数据库编码不是GBK/UTF8 | 初始化前确认数据库字符集 |
提示mysql_connect()未定义 | PHP 8移除了旧函数 | 切到PHP 7.x版本 |
| 暴力破解模块提示验证码错误 | 未带Cookie/Session | Burp里设置Cookie，启用宏刷新验证码 |
| 反序列化模块无反应 | Payload未URL编码 | 提交前对序列化字符串做URL编码 |
4.2 我踩过的几个坑
第一个坑是初始化不干净。如果之前装过一遍，后来改动库结构或删了表，重新访问安装页面可能会提示"已安装"而不让你重装。解决办法是打开phpMyAdmin，手动删除pikachu数据库，再重新走安装流程。
第二个坑是路径问题。很多人把压缩包解压后没有把内容单独放到一个文件夹，导致访问的时候路径里有pikachu-master和pikachu-master-master这种套娃结构。表面上能打开，但一旦涉及跨页面跳转的模块，比如CSRF和越权，路径失配就会出各种莫名其妙的bug。建议统一规范：解压后重命名为pikachu，放到WWW目录，所有操作都在这个路径下进行。
第三个坑是Burp Suite的代理设置。很多人在浏览器里能打开靶场页面，但Burp一开就访问不了，典型症状是页面一直转圈或报502。解决方法是确认Burp代理端口（默认8080）和浏览器代理设置一致，并确认HTTP History里能看到流量。另外一个进阶技巧：URL重定向模块需要跟随跳转才能看到效果，在Burp的Proxy Options里勾选Response Modification里的Unhide hidden form fields和Disable insecure redirects，能省不少事。
4.3 看源码比看答案有用
Pikachu每个漏洞场景里其实都给出了后端源码，这是它区别于很多靶场的一个优势。很多人在通关时第一反应是去搜索引擎找通关教程，但我强烈建议：先自己分析页面逻辑，再点开"提示"或"源码"按钮对照着看。
比如字符型SQL注入，你闷头试' or 1=1 --试不出来的时候，点开源码就会看到SQL语句是SELECT * FROM user WHERE name = '$name'。这时候你就明白了：注入的本质就是让开发者写的SQL语句按照你的意志"变形"。XSS模块也一样，源码里直接展示echo $message;还是echo htmlspecialchars($message);的区别，你一眼就能看出漏洞产生的根源。
学安全最忌"背答案式通关"。把每个页面的源码和漏洞产生原理对应起来，练完Pikachu，你再去看真实项目的代码审计，至少能建立起"看到什么写法会有什么漏洞"的条件反射。
5. 从靶场走向实战：把通关经验变成安全测试能力
5.1 靶场和真实业务的差距在哪
练完Pikachu不代表你就能对真实站点做渗透测试，这里面隔着好几层：真实系统有WAF拦截、有参数过滤、有代码框架的路由机制，而且你没有一个"源码"按钮可以点开确认后端逻辑。
但Pikachu给你练出的是"手感"和"判断力"——看见一个输入框，第一反应是测试闭合方式；看见一个文件上传点，下意识想到扩展名和Content-Type校验；看见一个登录框，先分析验证码机制到底在前端还是服务端。这种条件反射，恰恰是安全测试最核心的能力。我自己带人的时候发现，练过Pikachu和完全没练过的人，在面对一个真实授权的测试目标时，分析路径和效率完全不在一个层级。
有一点必须反复强调：在任何未授权系统上做漏洞测试都属于违法行为。Pikachu这类靶场存在的意义，就是让你在合法、可控的本地环境里积累经验。真正的实战能力，应该在授权范围内、通过SRC或众测平台逐步积累。
5.2 通关后建议深挖的几个修复点
如果你不只是想当攻击方，还想往蓝队或开发安全方向走，Pikachu其实也是很好的"反面教材"。每通一个漏洞，建议顺手把修复方案写一遍：
- SQL注入的修复：使用预处理语句（PDO预处理或MySQLi绑定参数），禁止拼接SQL。
- XSS的修复：对输出做HTML实体编码，配合CSP（内容安全策略）。
- CSRF的修复：关键操作增加Token校验，并验证Referer。
- 文件上传的修复：白名单机制校验扩展名，重命名文件，存储目录设为不可执行。
- 反序列化的修复：对输入做白名单类校验，禁用PHP魔术方法的危险调用。
我个人的做法是通关之后把每个模块对应的修复代码重新写一遍，跑通一个"安全版Pikachu"。这样一轮下来，你会发现自己对漏洞原理的理解深度明显不一样了。
5.3 后续学习路径建议
练完Pikachu，比较自然的下一个台阶是DVWA的中高难度模式、Sqli-labs（专门刷SQL注入的靶场）和Upload-labs（文件上传专项）。再往后可以接触CTF题目，从Web类的入门题开始，会打开一个更广阔的视野。
我在实际带教中还有一个感觉：很多人把靶场刷完就扔了。其实隔一两个月回来再刷一遍，往往会有新的收获。第一遍你可能照着Payload打，第二遍你能不看Payload自己构造，第三遍你开始琢磨漏洞背后的框架特性和绕过思路。同一个Pikachu，三个阶段的学习深度完全不同。
最后再分享一个我自己的习惯：每通一个模块，我习惯在笔记里画一张"漏洞认知卡"：触发条件、利用过程、修复方案、绕过变体各写一行。积累到后面，这套卡片比任何教程都值钱。Pikachu这个压缩包虽然只有几十MB，但把它练透，花在上面的时间绝对值回票价。
本文还有配套的精品资源，点击获取
