五分钟搭建Pikachu靶场：SQL注入手工绕过实战详解

做漏洞测试这一行，尤其是刚上手那段日子，最劝退的不是靶场题有多难，而是想练手的时候连个能打的环境都找不着。我自己前前后后试过不少方案，最后固定下来一套流程：本地起一个 Pikachu 漏洞测试平台，SQL注入、XSS、RCE、文件上传这些漏洞类型全部配好，五分钟以内就能开打。今天这篇就把快速搭建漏洞测试环境的方法和踩坑记录整理出来，顺带把靶场里两道特别典型的SQL注入题——参数加密场景和过滤字符后的手工注入——完整拆一遍。

1. 为什么非要在本地搭一套漏洞测试环境

1.1 本地靶场相比在线靶场的三个优势

网上其实有不少公开的在线靶场，注册个账号就能玩，打开浏览器就能测。但用下来你会发现，在线靶场有几个问题。第一是稳定性，高峰期经常卡顿，有时候题目页面直接打不开，正在测到一半断线了，session丢了又得重来。第二是题目不可控，在线平台给你什么题你就只能练什么题，不能改参数、不能换数据库、不能把过滤规则调严一点再练一遍。第三是没法看源码，很多在线靶场只给你一个输入框和回显，后端到底怎么写的完全看不到，练完之后只能记住"这个payload能出数据"，原理还是一知半解。

本地靶场刚好把这三个问题全解决了。装在自己电脑上之后，环境永远在线，想重置数据就重置，想改代码就改代码。更关键的是，你随时可以打开后端源码看眼，比如SQL注入那道题，直接翻到PHP文件，看一眼SQL语句是怎么拼接的，所有疑问当场就通了。我身边很多新手朋友，卡在"注入点判断"这个环节出不来，我让他们做一件事——把靶场源码打开，看一遍那几行SQL，立刻就从"背payload"变成了"理解payload"。

还有一个很容易被忽略的好处：安全边界清晰。所有测试流量都留在自己机器上，不碰公网目标。做安全测试这件事，授权边界非常重要，本地靶场练手是零风险、零争议的练习方式。

1.2 靶场平台怎么选：Pikachu为什么适合新手

市面上的开源靶场很多，各有各的侧重点。DVWA是最经典的老牌靶场，覆盖漏洞类型全面，但是难度跨度大，从最简单的命令注入到很难的CSRF token绕过都有，而且默认是全英文界面，新手光看懂菜单就要花点时间。sqli-labs是专门练SQL注入的靶场，关卡很多，从基础到各种绕过都有，但只覆盖SQL注入这一类漏洞，练完它你还得再找别的靶场练XSS、文件上传。upload-labs则是专攻文件上传漏洞的。

Pikachu这个平台的优势在于：全中文界面，漏洞类型覆盖广，从SQL注入、XSS、CSRF、RCE到文件上传、越权、目录遍历都有，而且每道题都带了明确的前端提示和后端代码说明。它本身是作为教学靶场设计的，所以题目难度对新手非常友好，不是那种故意刁难人的CTF题目，而是把真实漏洞场景简化之后搬到本地。更难得的是，里面还有一些带"进阶性质"的题目，比如参数加密、过滤字符绕过这类，用来练习手工注入和绕过思路特别合适。我的建议很直接：如果你只想搭一个靶场，那就选Pikachu；如果你想在SQL注入上练到更深的绕过技巧，可以再加一个sqli-labs，两个靶场并存也不冲突。

2. 五分钟起一套Pikachu环境

2.1 最省事的Docker部署

如果你电脑上已经装了Docker，那搭建Pikachu几乎是零成本的事。在Docker Hub上直接搜pikachu，找一个维护比较活跃、star数比较多的镜像拉下来就行。我自己的习惯是固定用一个本地端口，比如8090，避免和本机其他Web服务冲突。

bash复制docker search pikachu
docker run -d -p 8090:80 --name pikachu area39/pikachu

跑起来之后，浏览器访问 http://localhost:8090，如果跳转到了初始化页面，直接点击初始化按钮，脚本会自动创建数据库并导入数据。初始化完成后再访问首页，看到一个带"Pikachu"字样的中文界面，环境就算起来了。

这里要特别提醒一句：用Docker部署虽然快，但后续想改源码、加过滤规则、看后端逻辑，就得多一层容器文件映射。如果你打算长期练手并且想深入理解漏洞原理，我更推荐用源码部署的方式，把Pikachu直接跑在PHP集成环境里，改代码、打断点、看日志都方便得多。Docker更适合先体验一下，或者单纯需要一个环境来跑工具。

2.2 源码部署流程（适合想改代码的人）

源码部署也没有多复杂，核心就是"装一个PHP环境，把源码丢进去，初始化数据库"。我常用的方案是phpstudy，Windows和macOS都有对应版本，装好之后自带Apache、MySQL、PHP，版本切换也方便。

第一步，准备PHP环境。注意Pikachu的代码偏老，推荐PHP 7.x版本。PHP 8下大部分页面能正常跑，但个别模块会报一些废弃函数相关的兼容性提示，测试体验会打折。

第二步，下载Pikachu源码。GitHub上直接搜pikachu，项目名就是它，下载zip包或者git clone都行。解压之后把文件夹名字改成pikachu，丢到Web根目录下。

第三步，启动Apache和MySQL，访问 http://localhost/pikachu。首次访问会自动跳到初始化页面，点击初始化按钮，平台会自动创建数据库、导入表结构和数据。如果初始化失败，基本都是数据库连接配置的问题，打开 inc/config.inc.php 这个文件，把数据库地址、用户名、密码改成你本机的实际值，再重新初始化一次。

第四步，初始化完成之后刷新页面，看到Pikachu主界面就说明部署成功了。这时候我建议先打开"SQL注入"菜单下的前几个页面，随便点一点、提交几个正常参数，确认后端没有任何报错再开始练习。

2.3 部署完成后先做这几件事

环境起来之后别急着直接打题，我强烈建议先花三分钟做几件事。

第一，注册一个普通用户账号。Pikachu有些注入场景（比如HTTP头注入）需要登录态，提前把账号注册好，后面做题不用临时折腾。第二，打开Burp Suite，配置好浏览器代理，然后随便点一个Pikachu页面试试，确保Burp能正常抓到靶场的HTTP请求。后面所有手工注入测试都要依赖抓包改包，这一步不能省。第三，找到数据库配置文件，看一眼数据库名和表名结构。虽然注入过程中可以用 information_schema 现查，但提前了解一下Pikachu自带的表结构（比如成员表、用户表），做题的时候心里更有底。

3. 靶场里的SQL注入模块到底在练什么

3.1 从一处URL到一条SQL

Pikachu的SQL注入模块设计得很有层次。数字型注入、字符型注入、搜索型注入，这几个基础题分别对应了不同的SQL拼接方式。不管是哪种类型，漏洞产生的核心原因只有一个：用户的输入被当成SQL代码拼接进了查询语句。

拿字符型注入(get)来说，页面接收一个id参数，后端代码大概长这样：

php复制$id = $_GET['id'];
$sql = "select id,email from member where id='$id'";

这个场景里，单引号把变量包了起来，看上去好像挺安全，但问题在于：如果用户提交的不是一个普通数字，而是一段精心构造的字符串，比如说 1' and 1=1#，那拼接出来的SQL语句就变成了：

sql复制select id,email from member where id='1' and 1=1#'

后面的注释符 # 把原本的右单引号直接吞掉了，导致整条SQL的语义完全被用户控制。这就是注入的本质：数据和代码没有分离。用一个生活化的类比，就像你填一张空白申请表，填名字的空格不做任何校验，你往里填什么，表格最终就把什么当成"名字"打印出来。攻击者的工作，就是想办法让"名字"这个位置变成一段新的指令。

3.2 手工注入的通用流程

不管什么类型的SQL注入，手工测试的思路其实可以收敛成一套固定的流程。

第一步，判断是否存在注入。最常见的探针是加一个单引号，如果页面报SQL语法错误，说明输入被直接拼接进了SQL语句里。然后再用 and 1=1 和 and 1=2 对比看回显差异，进一步确认。

第二步，判断注入类型。数字型不用闭合单引号，字符型需要在payload里补单引号闭合，搜索型通常走的是 like '%keyword%' 这种拼接方式。判断方法很简单：你输入的内容和原来的SQL片段之间是什么边界关系，就用什么样的方式闭合。

第三步，判断字段数，也就是查询结果有几列。用 order by n 逐级增加数字，直到页面报错。比如 order by 3 正常、order by 4 报错，说明查询只有3列。

第四步，确定回显位，也就是哪一列的数据会直接显示在页面上。用 union select 1,2,3 这种占位payload，看数字出现在页面的哪个位置。这一步决定了后续爆数据时把查询表达式放在哪个位置。

第五步，爆数据。思路是先用 database() 拿当前数据库名，再通过 information_schema.tables 查表名，通过 information_schema.columns 查字段名，最后把目标表的数据select出来。

这套流程看着简单，但很多新手到了实际题目里还是会乱。原因就是没有把每一步的"判断依据"记牢。比如 order by 报错说明列数越界，union select 没数据说明字段数不对或者不匹配。这些判断标准需要在靶场里反复练，练到形成条件反射。

4. 实战一：参数加密场景的SQL注入测试

4.1 现象观察：请求里的参数怎么是乱码

Pikachu的SQL注入模块里，有一道专门演示"参数加密"的题目，这一题非常经典。页面上就是一个输入框，让你输入用户id查询信息。正常输入 1，页面能正常返回一条用户数据，看起来跟基础题没什么区别。但如果你开着Burp抓包，就会发现请求特别有意思。

http复制GET /pikachu/vul/sqli/sqli_10.php?id=MQ==&submit=1 HTTP/1.1

注意看id参数的值，不是明文数字 1，而是一串 MQ==。这个格式太眼熟了，就是Base64编码。把 MQ== 扔进Burp的Decoder或者任意一个Base64在线解码工具里，解出来就是 1。也就是说，前端先把用户输入做了一次Base64编码，再把编码后的内容作为参数传过去，后端拿到参数之后先解码再拼进SQL查询。

为什么专门设置这么一道题？因为它模拟了一个很常见的"伪防护"场景：很多业务系统觉得"参数不透明就安全了"，于是给参数做了一层编码或者加密，但实际上后端拿到数据后照样直接拼接SQL，过滤和参数化查询一概没有。加密本身没有解决注入问题，只是把攻击者的操作流程往后推了一步。

4.2 手工绕过的完整流程

这种题对工具的打击特别大。sqlmap这类自动化工具默认不会意识到"提交之前要先做Base64编码"，直接拿原始payload去打，打的是编码前的内容，后端解出来的根本不是你想要的注入语句，自然测不出漏洞。所以这道题必须手工来过。

第一步，确认编码逻辑。前面已经看到了，1 变成了 MQ==，基本可以断定是Base64。

第二步，测注入点。手动写一个payload，比如 1'，这串字符的Base64编码是 MSc=。把这个编码后的字符串替换到id参数里，请求变成这样：

http复制GET /pikachu/vul/sqli/sqli_10.php?id=MSc=&submit=1 HTTP/1.1

放行请求，页面直接抛出SQL语法错误。这说明什么？说明后端确实是把Base64解出来的内容拼进了SQL，而且 1' 破坏了原始SQL的结构。注入点确认，类型是字符型。

第三步，判断字段数。构造 1' order by 2#，整体做Base64编码，得到一长串，替换id参数提交，页面正常返回。再换成 1' order by 3# 编码后提交，页面报错。说明这个查询只有2列。

第四步，确认回显位置。构造 1' union select 1,2#，Base64编码后提交，页面上原来的用户信息位置出现了两列，一列回显数字 1，一列回显数字 2，回显位确认完毕。

第五步，爆数据。把要查的内容放到刚才回显 2 的位置，比如查当前数据库名和当前用户，payload写成 1' union select database(),user()#，编码后提交，页面上直接显示数据库名和数据库账号。继续查表名，可以用 group_concat(table_name) 把当前库所有表名一次性查出来，再挑一张目标表查字段、查数据。Pikachu环境里数据库表结构和字段名不必死记，以 information_schema 实际查询结果为准。

这里有一个细节必须提醒：Base64编码后的字符串可能包含 +、/、= 这些URL特殊字符。如果直接放在GET请求里，某些字符会被Web服务器或代理误解，导致后端解出来的内容不对。稳妥的做法是在Burp Repeater里手动做一次URL编码，尤其是 + 要变成 %2B，= 变成 %3D 或者干脆去掉末尾的 =，后者不影响Base64解码。我自己第一次做这道题，就是在 + 上栽了跟头，payload解码出来前端正常、后端解出来的却是乱码，查了半天才发现是URL编码的问题。

4.3 这类场景在真实业务中的意义

做完这道题，别急着往下翻，稍微停下来想一想。参数加密这个场景在真实业务里太常见了，很多接口的参数不是明文传输，有的是Base64，有的是AES加密，有的是前后端约定好的自定义编码。但加密和防护是两码事，加密解决的是传输可读性问题，参数化查询和输入过滤解决的才是注入问题。如果一个接口后端拿着解密后的参数直接拼SQL，那不管加密多复杂，注入漏洞依然存在。

碰到这种情况，核心思路就是"对齐编码"：抓包观察正常请求里参数长什么样，判断编码方式，然后把你手工构造的payload套上同样的编码规则再提交。工具在这个时候作用非常有限，手工思维才是解决问题的关键。Pikachu这道题虽然只是Base64，但练会了这个流程，以后遇到AES加密、签名字段之类更复杂的场景，思想是完全一致的。

5. 实战二：过滤字符后的手工注入测试

5.1 第一步：探测到底过滤了什么

过滤字符这道题，在很多平台里都有类似的版本，Pikachu之外的各类闯关靶场里也能看到它的影子。这类题的特点是不直接报错也不直接回显，而是后端先把某些危险字符替换成空字符串，再拼进SQL。你提交的payload如果碰了过滤规则，跟没提交一样；只有绕过过滤规则，注入才能继续往下走。

做题的第一件事永远是探测过滤规则，而不是直接拿大payload怼。后端到底过滤了什么、过滤了几种字符、是只过滤空格还是连关键字一起过滤，这些信息只能通过一个一个字符去试。

一个标准的探测过程是这样的：先提交 1' or 1=1#，如果页面返回了全部数据，说明单引号、or、等号、注释符都是可用的，过滤可能只针对空格。再提交 1' and 1=1#，如果返回结果异常或者跟 1' 一样报错，那可能是 and 被过滤了，也可能只是空格被过滤导致SQL语句语法被破坏。这时候就要用控制变量的方式，一组一组地试。

比较实用的小技巧是借助页面回显来反推。比如你提交 1' and 1=1#，页面报错；提交 1'/**/and/**/1=1#，页面正常返回。这一对比就说明空格被过滤了，但 and 还能用。如果提交 1' anandd 1=1# 也能正常返回，那大概率 and 也被过滤了，后端做的是替换成空操作，双写就能绕过。

5.2 用注释符替代空格绕过

过滤字符题里最常见的过滤项就是空格，因为几乎所有SQL注入payload都离不开空格。空格一旦被过滤，常规的 1' and 1=1# 会被替换成 1'and1=1#，SQL直接变成 where id='1'and1=1#'，其实这种写法在MySQL里可能还能碰巧跑通，但一旦加入 union select 这种多关键字payload，语法就彻底乱了。

解决办法是用MySQL的注释符 /**/ 来替代空格。/**/ 在SQL解析时会被当作空白处理，也就是说：

sql复制select id,email from member where id='1'/**/and/**/1=1#'

这条语句和带空格的版本在语义上是完全一样的，但空格字符不再出现，自然绕过了过滤规则。除了 /**/，换行符 %0a、Tab %09 在某些场景下也能起到分隔符的作用，不一定非要用注释符。做题的时候可以把这几种分隔符都试一遍，看哪种能过。

5.3 完整复现一次手工注入

以"过滤空格"的题为例，完整的手工注入流程是这样的。

先用 1' 测出注入点，页面报错。然后探测过滤规则，确认单引号、注释符、关键字都没问题，只有空格被过滤。接下来所有payload里面都不要出现空格，统一用 /**/ 分隔。

判断字段数，payload写成：

sql复制1'/**/order/**/by/**/2#

提交，页面正常。再改成 3，页面报错。列数确定是2列。

确认回显位，payload写成：

sql复制1'/**/union/**/select/**/1,2#

回显两个数字，回显位确认。接下来爆库名，把 database() 放到第二个回显位：

sql复制1'/**/union/**/select/**/1,database()#

页面显示当前数据库名。继续爆表名，用 group_concat 把表名拼成一行输出：

sql复制1'/**/union/**/select/**/1,group_concat(table_name)/**/from/**/information_schema.tables/**/where/**/table_schema=database()#

拿到表名之后，再针对目标表查字段名、查数据。整个过程看起来只是比普通注入多了几个 /**/，但实际做的时候最关键的是要保持头脑清醒，每构造一个payload之前先想清楚：这里面有没有被过滤的字符。

还有一个细节，在浏览器地址栏直接提交payload时，# 要URL编码成 %23，否则会被当成页面锚点，根本不会发到服务端。如果是在Burp Repeater里操作，直接把 # 放进请求正文就行，Burp不会画蛇添足。

5.4 再进阶一点的绕过思路

过滤字符这关有个好处：做完一道题，你就掌握了绕过思路的"母版"，以后再遇到各种变体都能举一反三。

如果过滤的不只是空格，还包括 and、or 这些关键字，可以考虑大小写混写，比如 AnD、UnIoN，前提是过滤规则没有做大小写归一化。如果大小写也过滤了，试试双写，ununionion 后端替换掉 union 之后恰好剩下 union，这个思路在过滤型WAF里经常能生效。如果 select 也被过滤，还能用注释符拆分关键字，比如 sel/**/ect，某些过滤规则只匹配完整关键字，注释符会打断匹配。

如果阻塞点在于等号被过滤，用 like 替代；逗号被过滤，考虑用 join 或者子查询。这些说到底都是同一个思想：先探测规则，再针对规则构造对应的替代方案。没有万能payload，只有按规则定制的payload。

6. 搭建和测试过程中的高频问题排查

6.1 环境起不来怎么办

我在帮别人排查Pikachu环境问题时，遇到的坑基本集中在这几个方向：

6.2 注入payload没反应时按什么顺序排查

练SQL注入时最崩溃的瞬间，就是你精心构造的payload提交出去，页面毫无反应，或者干脆报一个看不懂的错误。这种时候最忌讳瞎试，得按顺序排查。

先看请求本身。用Burp抓包确认你提交的参数确实到达了服务端，参数名没写错、请求方法是POST还是GET、Content-Type对不对。再看编码。这一条在参数加密题里是必须检查的，payload是否已经按后端要求的编码方式处理过，Base64、URL编码、双重编码，漏一步都不行。然后看过滤。把payload里的空格、关键字逐个替换成替代写法，确认没有被后端过滤掉。再看列数和回显位。 order by 的列数判断是不是在当前查询里成立，回显位是不是选对了。如果这些都查完还是没反应，那就从最小探针重新开始，一个单引号、一个 and 1=1，一步一步重建可信的判断链条，不要抱着一个失败的大payload反复改。

6.3 练习中的安全边界

写这段是想提醒所有看到这篇文章的人。靶场是用来练习的，练手的目标是理解原理，而不是攻击真实目标。任何未获得授权的测试行为都有法律风险，这一点没有任何模糊空间。本地靶场的价值恰恰在于，你可以在一个完全合法、完全可控的环境里，随便折腾、随便试错，把过滤器打开、调严、换规则，反复打反复练，直到把原理彻底吃透。练习完之后勤快点，重置一下数据库，保持环境干净，下次再练的时候状态也是最新的。

7. 最后说点实操心得

练SQL注入这几年，我最大的体会就是：工具能帮你省时间，但永远替代不了手工过一遍流程。尤其参数加密、过滤字符这种场景，工具要么识别不了编码逻辑，要么被过滤规则卡死，最后能解决问题的还是脑子里那套"探测-假设-验证"的循环。做题不是为了交差，是为了把每一步的判断依据刻进直觉里。

还有一个小建议：本地靶场的源码是可以随便改的。我在练过滤字符的时候，经常会临时改一下后端过滤规则，比如把空格过滤改成同时过滤 and 和 or，再重新打一遍。这种"自己给自己加难度"的练习方式，比反复刷同一道题有效得多。等你能在自定规则下依然完成一次完整的手工注入，再回头看靶场里的这些题，会变得非常轻松。后期你还可以在这个环境基础上挂WAF插件、接入数据库日志，把练习场景模拟得更接近真实业务，这些都是在Pikachu平台上可以继续深挖的方向。