Pikachu靶场通关教程

Pikachu 靶场通关 WP：本地环境下的 Web 漏洞练习记录

靶场地址：http://127.0.0.1:8860/
环境说明：本机授权靶场，仅用于课程实践和漏洞原理学习。
工具：浏览器、Burp Suite、小皮 / PHPStudy 环境。

提交课程报告请勿使用下面原图！！！
提交课程报告请勿使用下面原图！！！
提交课程报告请勿使用下面原图！！！

0x00 环境确认

先访问首页，确认 Pikachu 已经跑起来。页面正常加载，左侧菜单能展开，说明本地 Web 服务和 PHP 环境没问题。

这一步没什么技巧，但很重要。后面很多问题如果页面没响应、数据库连不上、菜单打不开，排查成本会很高。

0x01 暴力破解

先从登录口开始。Pikachu 的暴力破解模块很适合观察登录逻辑：用户名、密码、验证码、token 分别对爆破有什么影响。

基于表单的爆破

入口页面是普通登录框：

先用常见弱口令测试。这里的关键不是“猜对密码”，而是看登录接口有没有失败次数限制、错误提示是否统一、是否能被 Burp 重放。

尝试 payload：

username=admin password=123456

成功登录后，页面返回登录成功信息：

用 Burp 看请求和响应，可以更直观看到登录参数和成功回显。

验证码和 token

继续看验证码。客户端验证码场景的核心问题是：如果校验只在浏览器前端做，攻击者可以直接改请求，前端限制就没意义。

客户端验证码绕过时，重点看请求是否真的把验证码交给服务端校验。

token 防爆破场景则相反。每次请求携带 token 后，简单重放会受到限制。

这一组打完之后可以得到一个很清晰的结论：登录防护必须落在服务端，前端限制最多只能改善体验，不能当作安全边界。

0x02 XSS

接着看输入输出问题。Pikachu 的 XSS 模块覆盖比较完整：GET、POST、存储型、DOM 型、过滤绕过、href 输出、JS 输出都有。

反射型 XSS

先从 GET 型开始。页面有一个输入点，提交后内容会回显到页面。

直接尝试经典 payload：

<script>alert(1)</script>

页面触发脚本，说明输入被当成 HTML/JS 解释执行了。

存储型和 DOM 型

存储型 XSS 的危险点在于 payload 会落库。只要后续有人访问这个页面，就可能触发。

DOM 型 XSS 的触发点在前端。这里要盯住前端 JS 怎么处理 URL 参数、hash 或 DOM 内容。

过滤绕过场景则说明黑名单并不可靠。只要过滤规则不完整，换标签、换事件、换大小写都可能绕过去。

这一部分的核心不是记 payload，而是记住输出位置。输出到 HTML、属性、JS 字符串、URL 参数里，修复方式都不一样。

0x03 CSRF

XSS 是让用户浏览器执行脚本，CSRF 则是借用户已经登录的身份发请求。Pikachu 的 CSRF 场景很适合看“只靠 Cookie 识别身份”的问题。

GET 修改资料

进入 CSRF(GET)，登录后修改资料。这个场景里，资料修改参数直接出现在 URL 中。

修改资料后观察请求参数：

成功修改：

用 Burp 重放请求，可以看到只要 Cookie 有效，请求本身没有额外 token 约束。

POST 和 token

POST 场景只是把参数从 URL 移到请求体，本质仍然要看有没有 token 和来源校验。

token 场景能体现防护差异：请求里出现一次性随机值后，伪造请求的成本会上升。

CSRF 的修复重点很明确：敏感操作加 token，校验 Origin / Referer，Cookie 配置 SameSite，重要操作做二次确认。

0x04 SQL 注入

SQL 注入是 Pikachu 里内容最多的一块。这里我按先易后难打：字符型、数字型、搜索型，再到 insert/update、delete、Header、布尔盲注、时间盲注、宽字节。

字符型注入

字符型场景需要闭合引号，再拼接条件。

payload：

' or '1'='1

页面返回非预期数据，说明查询条件被改写。

数字型和盲注

数字型 POST 不需要闭合引号，直接拼接逻辑条件即可。

1or1=1

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

用 Burp Repeater 重放这个请求，更方便观察参数变化和响应结果。

搜索型注入一般落在like '%keyword%'这种语句里。

布尔盲注看页面真假差异：

时间盲注看响应延迟：

1andsleep(5)

SQL 注入通关后，修复思路其实很统一：参数化查询、预编译、最小权限、统一错误信息。过滤关键字不是根治办法。

0x05 RCE

RCE 这块分两类：命令执行和代码执行。前者是用户输入进入系统命令，后者是用户输入进入解释器。

ping 命令执行

页面原本功能是 ping 一个 IP。

先正常输入127.0.0.1，确认功能。再用命令连接符追加命令：

127.0.0.1 & whoami

响应里出现命令结果：

Burp 里可以看到 payload 和响应中的执行结果。

eval 代码执行

eval 场景更直接。只要输入被当成 PHP 代码执行，就可能造成严重后果。

RCE 的修复原则是：不要让用户输入进入命令解释器或代码解释器。如果必须调用命令，只能传递白名单参数。

0x06 文件包含

文件包含的关键点是路径可控。用户输入如果直接进入include/require，就可能包含到非预期文件。

入口：

尝试路径穿越：

../../../../../../Windows/win.ini

成功包含本地文件：

remote 场景用于理解远程包含风险：

修复时不要让用户直接控制文件路径。可以使用固定路由映射，例如page=about只映射到固定文件。

0x07 文件上传

文件上传的思路是先看校验在哪里做：前端、MIME、后缀、文件内容、图片解析。只要校验点单一，就可能绕过。

客户端校验绕过

入口：

只靠前端判断后缀是不可靠的，可以改前端或改请求。

上传成功：

MIME 和 getimagesize

servercheck 场景会看 MIME：

用 Burp 把Content-Type改成图片类型：

请求放行后上传成功：

Burp 证据如下：

getimagesize 场景则说明仅判断图片结构也不够。

上传修复不能只做一层。后缀、MIME、文件头、重新编码、存储目录、执行权限都要一起考虑。

0x08 文件下载

文件下载漏洞和文件包含很像，都是路径边界问题。区别是这里常见入口是下载链接。

观察下载参数，尝试修改文件名或路径：

成功读取非预期文件：

安全做法是下载接口只暴露文件 ID，服务端根据 ID 查询真实路径并校验权限。

0x09 越权漏洞

越权看两个问题：能不能看别人的数据，普通用户能不能做管理员操作。

水平越权

入口：

通过修改用户标识或访问目标，尝试读取其他用户信息。

成功看到非本人数据：

垂直越权

普通用户访问管理新增页：

操作成功：

越权修复的核心是服务端鉴权。前端隐藏按钮、隐藏菜单没有安全意义。

0x0A 目录遍历

目录遍历主要测试../是否能跳出预期目录。

先正常访问：

再构造路径穿越：

修复时要规范化路径，并确认最终路径仍在允许目录下。

0x0B 敏感信息泄露

敏感信息泄露不一定需要复杂 payload，很多时候是接口返回太多。

通过枚举或查询用户信息，观察返回字段：

结果中出现不应公开的信息：

接口返回应遵循最小必要原则，错误信息和调试信息也不能直接暴露。

0x0C 反序列化

PHP 反序列化的入口是用户可控的序列化字符串。

构造对象序列化 payload：

服务端解析后出现预期回显：

不可信数据不要直接反序列化。如果必须使用，应限制允许类，并避免魔术方法里出现文件操作、命令执行等危险逻辑。

0x0D XXE

XXE 关注 XML 解析器是否允许 DTD 和实体解析。

入口：

payload：

<?xml version="1.0"?><!DOCTYPEnote[<!ENTITYxxe"XXE_ENTITY_SUCCESS">]><name>&xxe;</name>

提交后实体被解析：

Burp 中可以看到完整 XML 请求和响应中的实体内容。

修复时应禁用外部实体和 DTD，并限制 XML 输入大小和解析深度。

0x0E URL 重定向

URL 重定向漏洞的关键是跳转目标是否可控。

修改跳转参数：

浏览器跳转到指定位置：

登录、支付、授权相关跳转尤其要谨慎。安全做法是白名单跳转，不接受任意外链。

0x0F SSRF

SSRF 是让服务端代替攻击者发请求。Pikachu 里有file_get_contents和curl_exec场景。

入口：

把 URL 指向本地靶场内部资源：

http://127.0.0.1:8860/vul/ssrf/ssrf_info/info1.php

页面返回服务端请求到的内容：

curl 场景：

Burp 中能看到请求参数里的内部 URL，以及响应里的内部资源内容：

SSRF 防护需要限制协议、域名、IP 段和服务端出网范围，尤其要禁止访问本机、内网和云元数据地址。

0x10 总结

Pikachu 打完后，能明显感觉到 Web 漏洞并不是孤立的 payload 集合，而是几类安全边界反复失守：

1. 用户输入进入解释环境：SQL、命令、代码、XML、HTML。
2. 前端限制被当成安全控制：验证码、文件类型、价格、按钮权限。
3. 服务端权限判断不完整：只判断登录，不判断资源归属和角色权限。
4. 文件和 URL 边界不清：包含、下载、上传、SSRF、目录遍历。
5. 返回信息过多：错误信息、用户数据、调试信息泄露。

如果从开发视角反推防护，优先级大概是：

• 参数化查询和上下文编码；
• 服务端统一鉴权；
• 严格白名单和路径边界；
• 文件上传隔离；
• 禁用危险函数和危险解析配置；
• 最小权限和日志审计。

这套靶场适合反复练。第一次可以按菜单通关，第二次建议每个点都配合 Burp 看请求，第三次再从代码角度反推漏洞产生的位置。这样比单纯背 payload 有用得多。