做 PHP 源代码漏洞分析这些年踩过的坑比读过的代码行数还多。这篇东西不讲概念只讲实操拿到一套 PHP 项目源码怎么从入口文件一路追到危险函数怎么判断一条数据流是不是真的可控怎么把“看起来像漏洞”变成“能稳定复现的漏洞”。核心关键词是 PHP 源代码漏洞分析但我不打算把它写成一份教科书。它解决的问题很具体很多同学能跑通扫描器、能看懂别人的 writeup轮到自己面对几千个 PHP 文件时就不知道从哪个文件开始读、读到哪一行该停下来标记。如果你是会写 PHP 但没做过代码审计的开发或者是想从“会打靶”转到“会看源码”的安全爱好者又或者是要给自家老项目做一次安全体检的技术负责人下面的内容都能直接拿去用。我会按“想清楚—拆开看—动手跑—踩坑复盘”的顺序展开中间穿插大量模拟示例代码代码全部是示意片段不指向任何真实系统。1. 先搞清楚 PHP 源码审计到底在找什么1.1 运行模型决定了漏洞长相很多人一上手就去背敏感函数表这是本末倒置。PHP 的漏洞形态是被它的运行模型塑造出来的理解了模型函数表根本不用背。PHP 是“每次请求重新构建一遍世界”的语言脚本执行完进程里的变量、全局状态通常就清空了没有常驻内存的概念常驻的常驻进程模式是另一套玩法这里不展开。这意味着绝大多数漏洞是“单次请求内可完成”的类型参数拼进 SQL 就立刻查、参数拼进命令就立刻执行。这个模型还带来一个后果输入来源极其扁平。$_GET、$_POST、$_COOKIE、$_REQUEST、$_SERVER、php://input、上传的$_FILES基本就是全部的外部数据入口。你在审计时要做的事本质上就是枚举这些入口然后顺着赋值、传参、函数调用看这些数据最终流到了哪里。你不需要理解复杂的线程调度也不需要关心内存布局只要会追变量。反过来说PHP 项目里最危险的结构往往是“全局配置 自动加载”这套东西。很多老项目把数据库连接、路径配置、模板目录都塞进一个config.php然后各处include。这类文件读一遍你就能知道整个项目的数据会流向哪个数据库对象、哪个模板引擎、哪个文件目录。我在实际审计中读完入口和配置这两层对项目的危险面就已经有了七成把握。另一个常被忽略的点是版本。同样一段代码跑在 PHP 5.6 和 PHP 8.2 上可利用性可能完全不同。弱类型比较、反序列化行为、libxml 默认是否加载外部实体、preg_replace的/e修饰符这些差异直接决定了一个点能不能打。所以我在看任何项目之前第一件事是找composer.json、composer.lock、README、部署脚本里写的版本约束实在找不到就看代码里有没有用 PHP 8 才有的语法比如构造器属性提升、match表达式、命名参数用这个反推版本区间。1.2 审计的本质是追一条数据流把话说透代码审计找的不是“危险函数”而是“从可控输入到危险函数的完整路径”中间没有有效过滤。这条路径上的三个要素缺一不可。第一是可控性。参数确实来自用户而且攻击者能自由控制内容。有些字段看着是$_GET实际上前面被intval()转过或者只允许某几个枚举值那它就不算可控。第二是可达性。这段代码真的会被执行到吗大量历史遗留项目里有成片的死代码或者被废弃的控制器追了半天发现路由根本不会指向它。判断可达性靠的是路由配置、index.php里的分发逻辑、框架的自动路由规则。第三是过滤有效性。中间可能有addslashes、htmlspecialchars、白名单校验、正则匹配。你需要判断这些过滤针对的是不是当前这个汇点。htmlspecialchars对 XSS 有用对 SQL 注入基本没用addslashes在 GBK 编码下还有宽字节问题。这三个要素任意一个不成立这个点就不成立。我见过太多新手把“有可控变量”直接等同于“有漏洞”然后在报告里写一堆没法复现的东西最后被开发一句话打回来“这个参数前面转成整数了。”提示审计时养成一个习惯每标记一个疑似点就写下三行备注——输入从哪来、经过哪些函数、汇点是什么。写不出来这三行基本就是错觉。1.3 开始之前要划清的三条线动手之前必须把边界说清楚这不是形式主义是保护自己。第一条是授权线。只审计你拥有书面授权的代码。公司内部项目走内部流程开源项目按项目的安全披露政策来自己的练习项目随便折腾。没有授权就去翻别人的生产代码性质完全不同。第二条是环境线。绝对不要在真实生产环境上做验证。用隔离的容器或者虚拟机跑一份代码副本数据库用模拟数据网络出口做限制。反序列化、命令执行这类验证一旦溢出后果不可控。第三条是数据线。验证用的数据全部自己构造不要把真实用户数据导进测试环境。涉及敏感信息的字段在报告里做脱敏处理。这三条线画清楚之后剩下的就是纯技术活。我个人的习惯是先花半天时间只读不写把所有 PHP 文件列出来按目录结构过一遍标记出控制器、模型、公共库、第三方依赖四个大类。这一步看着慢实际能省下后面几倍的返工时间。2. 整体思路与拆解从入口到汇点怎么走2.1 先画地图别急着读代码面对一个几千文件的项目最容易犯的错是从第一个文件开始顺序读。读到第三百个文件的时候你已经忘了第一个文件里有什么。正确做法是先画地图。地图分三层。第一层是入口index.php、admin.php、api.php这类直接暴露给 Web 服务器的文件以及public/目录下的所有 PHP。用命令行的全文搜索扫一遍把根目录和入口目录下的文件列出来。第二层是分发入口文件里通常有一个路由表或者一段switch把?mxxxayyy映射到具体的类和方法。现代框架靠自动路由规则写在配置文件里老项目靠手写include。这一层决定了“哪些控制器能被我碰到”。第三层是公共设施数据库封装类、模板引擎、上传处理、文件读写工具类、日志类。这些是汇点最密集的地方也是复用最多的地方。一个公共的查询封装如果有问题可能一次性炸掉几十个接口。三层画完我会得到一张“输入到功能”的对照表。实际审计就从这张表里挑软柿子优先看文件上传、导入导出、模板渲染、参数多的搜索接口。这几类功能天然处理复杂输入出问题的概率最高。2.2 三条审计路线的取舍实际工作里我常用三条路线它们不是互斥的而是根据项目情况组合。路线一关键词驱动。用全文搜索直接搜危险函数eval、system、exec、shell_exec、popen、proc_open、assert、include、require、unserialize、extract、parse_str、call_user_func等等。搜出来之后逐个回溯变量来源。这条路线的优点是快十分钟就能摸清一个中型项目的危险面缺点是只能发现“显式调用”对框架封装、动态调用、链式调用的覆盖很差。路线二数据流驱动。从所有外部输入入口出发正向追踪。优点是不遗漏尤其擅长发现“参数绕了三层才到汇点”的情况缺点是非常耗时间一个有几百个接口的项目纯手工追完需要以周计。路线三功能驱动。按业务功能模块切一个模块一个模块地读完整逻辑。优点是能发现业务逻辑漏洞比如越权、支付金额篡改、验证码复用这类问题用关键词和数据流都很难自动发现缺点是效率最低且高度依赖你对业务的理解。我的实际组合是先用路线一快速摸底产出一份“高危文件清单”再用路线三挑清单里的重点模块精读最后用路线二对精读中发现的每一个可控点做完整回溯确认可达性和过滤。三轮下来覆盖率和效率的平衡基本能接受。2.3 敏感函数清单要按危险等级分层函数清单不能平铺必须分层否则你会被几十个echo淹死。危险等级典型函数或语法直接后果审计权重极高eval、assert字符串模式、create_function、preg_replace带/e任意代码执行每处必看高system、exec、shell_exec、passthru、popen、proc_open、反引号命令执行每处必看高unserialize、include/require带变量、file_put_contents带变量反序列化利用、任意文件包含、任意写入每处必看中高mysql_query/mysqli_query/PDO::query带拼接、-where()带原始字符串SQL 注入结合参数化情况看中file_get_contents、curl_exec、fsockopen带用户 URLSSRF、任意文件读取看 URL 来源与协议限制中header、setcookie带用户输入、模板输出未转义响应头注入、XSS看输出上下文低echo、print、var_dump信息泄露只关注敏感信息分层之后审计顺序就明确了先把“极高”和“高”全部过一遍这部分通常只占代码量的百分之几但覆盖了大部分能直接拿 shell 的问题。然后再处理“中高”和“中”这部分量大需要结合业务判断。还有一个容易漏的类别动态调用。$func($arg)、call_user_func、call_user_func_array、array_map、usort的回调参数、$$var可变变量。这类写法在框架里到处都是用关键词搜函数名搜不出来只能靠通读代码时留意。我个人的经验是看到$后面直接跟变量名再跟括号立刻停下来看这个变量能不能被外部影响。2.4 手工污点分析的四个动作真正落到每一行代码上污点分析其实就是四个反复执行的动作。动作一标记源。看到$_GET、$_POST、$_COOKIE、$_REQUEST、$_FILES、$_SERVER[HTTP_*]、php://input立刻在变量上打一个“脏”标记。同时注意别名$input array_merge($_GET, $_POST)之后$input里所有元素都是脏的。动作二跟随传播。赋值、拼接、数组操作、函数传参、返回值脏标记跟着走。这里有个高频陷阱脏数据经过explode、json_decode、base64_decode之后很多人下意识觉得“处理过了应该安全”实际上脏标记一点没少反而多了一层编码绕过。动作三检查净化。遇到类型转换intval、(int)、floatval、白名单比较、in_array带true、正则全匹配、hash_equals、password_verify可以视为该路径被切断。但要逐个确认净化是否真的覆盖了目标汇点的语义比如intval对 SQL 注入有效对文件路径就完全无效。动作四到达汇点判定。脏数据进入危险函数时逐个判定这里的上下文是什么拼接方式是什么有没有二次转义能不能构造出有效载荷这四个动作说起来简单实际执行时最大的难点是“跨文件”。脏数据传进一个方法方法内部又调了另一个类的静态方法静态方法里再拼进 SQL。这条链可能要跨五六个文件中间还有接口和多态。我的做法是用纸笔或者纯文本笔记画出调用链每跨一层就记一行“文件:行号 - 函数名”追丢了就回到最后一个确认点重来。3. 高频漏洞类型的逐个拆解与验证姿势3.1 SQL 注入拼接和参数化的那条细线PHP 项目里 SQL 注入依然是最常见的洞原因很简单预处理只解决“值”不解决“结构”。看这段模拟代码$keyword $_GET[kw] ?? ; $order $_GET[order] ?? id; $sql SELECT id, title FROM article WHERE title LIKE %{$keyword}% ORDER BY {$order} DESC; $rows $pdo-query($sql)-fetchAll();$keyword拼进了 LIKE 的字符串里虽然外面有引号但攻击者输入% OR 11之类的构造就能突破$order更直接完全没包裹属于典型的结构位注入。很多人看到项目用了 PDO 就放心了其实-query()直接执行拼接字符串和预处理一点关系都没有。正确姿势是所有“值”位置用占位符绑定所有“结构”位置表名、字段名、排序方向、LIMIT偏移用严格白名单。$allowOrder [id, created_at, views]; $order in_array($_GET[order] ?? , $allowOrder, true) ? $_GET[order] : id; $stmt $pdo-prepare(SELECT id, title FROM article WHERE title LIKE ? ORDER BY {$order} DESC); $stmt-execute([% . $keyword . %]);注意in_array第三个参数true这是严格比较少了它就会出现0 id这类历史遗留的松散匹配问题。审计时我重点看三类地方。一是ORDER BY、GROUP BY、LIMIT后面的变量这些位置预处理绑不了开发往往图省事直接拼。二是IN (...)子句很多人用implode拼数组如果数组元素没经过整数校验就是注入点。三是框架的“原生查询”方法比如某些 ORM 提供的whereRaw、-query()这些入口标注着“原样执行”是注入高发区。还有一个隐蔽点二次注入。用户提交的内容先被addslashes处理存进数据库取出来的时候斜杠已经没了再拼进新 SQL 就还原成了注入。验证这类问题必须走“写入—读取—再使用”的完整流程光看单点代码看不出来。3.2 文件包含与路径穿越点号与截断的老账文件包含的危害在于“包含即执行”。被包含的 PHP 文件里的代码会以当前上下文执行所以只要能控制包含路径哪怕只能包含一个上传的图片图片里藏 PHP 代码也可能直接拿到代码执行。$page $_GET[p] ?? home; include __DIR__ . /pages/ . $page . .php;这段代码的问题在于$page完全没过滤。攻击者可以构造../../uploads/avatar这类路径穿越也可以利用php://filter之类的流包装器读取源码。验证时我通常先试相对路径穿越再试流包装器最后试空字节和历史截断这些在现代版本已失效但老项目里偶尔还能撞上。修复的思路有三层。第一层是白名单只允许预定义的页面标识映射到固定文件。$map [home home.php, about about.php, help help.php]; $key $_GET[p] ?? home; if (!isset($map[$key])) { http_response_code(404); exit; } include __DIR__ . /pages/ . $map[$key];第二层是路径校验用realpath求出绝对路径再判断是否以允许的根目录开头。$base realpath(__DIR__ . /pages); $target realpath($base . / . $page . .php); if ($target false || strpos($target, $base . DIRECTORY_SEPARATOR) ! 0) { exit(invalid path); }要注意strpos的判断必须带后面的分隔符否则/pages_evil这种同前缀目录能绕过。第三层是配置兜底open_basedir限制 PHP 能访问的目录范围关闭allow_url_include现代版本默认关闭上传目录禁止执行 PHP。这三层是纵深防御缺一层都可能被绕过但全上之后攻击成本会高很多。路径穿越在“下载文件”“读取日志”“导出报表”功能里同样高发判断逻辑和包含完全一致只是汇点从include变成了readfile、file_get_contents。3.3 命令执行与代码执行最容易被低估的一类命令执行在 PHP 里通常出现在“系统工具调用”场景比如 ping 检测、图片处理、PDF 转换、压缩打包。看这段$host $_POST[host]; $out shell_exec(ping -c 1 . $host); echo pre{$out}/pre;直接拼 shell攻击者输入127.0.0.1; id就能执行任意命令。这类代码在运维工具、监控面板里非常普遍。有人会用escapeshellarg来修但这两个函数用错场景就没效果escapeshellarg($s)把整个字符串包成单个参数适合“一个参数就是一个值”的场景。escapeshellcmd($s)转义的是 shell 元字符但不保证参数边界两个叠加使用反而会出问题。更稳的做法是彻底不用 shell用proc_open传数组形式的参数PHP 7.4 起支持数组形式避免 shell 解析或者干脆用纯 PHP 实现功能。$cmd [ping, -c, 1, $host]; $proc proc_open($cmd, [1 [pipe, w], 2 [pipe, w]], $pipes);即便如此$host也必须先做格式校验比如只允许合法 IP 或域名正则否则参数注入依然存在。代码执行的核心是eval和assert。现代项目里直接写eval($_POST[x])的少了但间接的还有模板引擎的“沙箱逃逸”、表达式解析器、规则引擎、preg_replace的/e修饰符PHP 7 已移除只在老项目里出现、create_functionPHP 8 已移除。审计时看到“用户可以自定义公式/规则/表达式”的功能一定要重点看它怎么解析和执行。这里补一个判断技巧eval里的内容如果能通过外部输入控制哪怕一部分就是极高危。因为 PHP 代码执行不需要“构造完整语句”eval拼接一个分号就能插入任意逻辑不存在“只能执行表达式”的限制。3.4 反序列化魔术方法串起来的链反序列化漏洞的判定分两步先看有没有unserialize的入口再看有没有可用的魔术方法链。入口通常藏在“记住我”“偏好设置”“缓存”“队列消息”这些地方$pref $_COOKIE[pref] ?? ; if ($pref ! ) { $data unserialize(base64_decode($pref)); $theme $data[theme] ?? light; }这段的问题不只是“能不能控制对象”更在于unserialize遇到对象时会自动触发__wakeup、__destruct、__toString这些魔术方法。如果项目里存在一个类它的__destruct里做了“删除文件”“写日志”“发请求”这类动作而属性又是可控的就构成了一条利用链。审计反序列化的方法是“反向找”先把项目里所有定义了魔术方法的类列出来看每个魔术方法里做了什么危险动作属性是否来自对象字段再回到入口处看能不能构造出这个类的序列化字符串。这条链经常跨好几个类__toString触发另一个对象的__call__call里又调了某个工具类的__destruct。所以我在做反序列化审计时一定会画一张“类—魔术方法—危险动作”的关系图。修复思路很干脆能用json_decode就不要用unserialize必须用时加allowed_classes白名单。$data unserialize($raw, [allowed_classes [UserPref, ThemeConfig]]);注意allowed_classes false是完全禁止对象只保留数组和标量这是最安全的配置。另外序列化数据如果来自 Cookie 或表单一定要加签名校验否则攻击者可以随意篡改。3.5 文件上传不要相信浏览器给的类型上传功能几乎每个后台都有也是漏洞最集中的地方。最典型的错误写法if ($_FILES[file][type] image/png) { move_uploaded_file($_FILES[file][tmp_name], uploads/ . $_FILES[file][name]); }$_FILES[file][type]是客户端提交的Content-Type抓个包随便改。$_FILES[file][name]更是完全不可信攻击者可以传../../shell.php做路径穿越也可以传shell.php配合可执行的上传目录直接拿 shell。正确的校验顺序是先校验大小和数量再校验扩展名白名单再校验真实文件类型读文件头最后重命名并落到不可执行的目录。$allowExt [jpg, jpeg, png, gif, webp]; $ext strtolower(pathinfo($_FILES[file][name], PATHINFO_EXTENSION)); if (!in_array($ext, $allowExt, true)) { exit(bad ext); } $finfo new finfo(FILEINFO_MIME_TYPE); $mime $finfo-file($_FILES[file][tmp_name]); $allowMime [image/jpeg, image/png, image/gif, image/webp]; if (!in_array($mime, $allowMime, true)) { exit(bad mime); } $name bin2hex(random_bytes(16)) . . . $ext; $dest __DIR__ . /uploads/ . $name; move_uploaded_file($_FILES[file][tmp_name], $dest);几个细节值得展开。pathinfo取扩展名之后一定要strtolower否则.PHP能绕过白名单扩展名白名单比黑名单可靠得多黑名单永远漏phtml、phar、php5这些finfo读的是文件头比客户端声称的类型可靠重命名用随机串避免覆盖已有文件和路径穿越上传目录的 Web 服务器配置里必须禁止执行脚本。还有一个经常被忽略的风险Phar 反序列化。某些文件操作函数比如file_exists、getimagesize、filesize在接收phar://协议路径时会触发 Phar 元数据的反序列化。如果上传功能允许传 Phar 格式文件且路径可控就可能绕过“只能传图片”的限制触发反序列化链。审计时看到phar://或者用户可控路径传给文件函数要顺着这个方向查。3.6 弱类型、变量覆盖与鉴权绕过PHP 的松散比较是历史包袱很多鉴权逻辑栽在这上面。$token $_GET[token] ?? ; if ($token $user[token]) { /* 登录成功 */ }在老版本PHP 7 及以前0 abc结果为真因为字符串被转成了数字 0。如果$user[token]是哈希值还可能撞上0e开头的“魔术哈希”——两个不同字符串的 MD5 都以0e开头时比较会把它们都当成 0从而相等。PHP 8 修改了比较规则数字与字符串比较时会把数字转成字符串这类绕过在 8 上大多失效但老项目依然大量存在。正确的写法只有一种用hash_equals做恒定时间比较或者统一用做严格比较。if (hash_equals($user[token], $token)) { /* ok */ }变量覆盖是另一类老问题。extract($_GET)、parse_str($str)不带第二个参数、$$var这类写法都能让外部输入直接覆盖内部变量。最经典的利用是覆盖配置文件里的变量foreach ($_GET as $k $v) { $$k $v; } // 后面某处 if ($isAdmin) { /* 管理操作 */ }攻击者传?isAdmin1就提权了。这类代码在现代项目里少见但老系统和一些“模板参数注入”场景仍然存在。审计时搜extract、parse_str、$$再看作用域里有没有关键布尔变量。鉴权绕过还有一类是逻辑层面的接口只在前端做了按钮隐藏后端接口没校验角色或者校验用$_REQUEST而攻击者可以用不同位置的参数覆盖再或者删除请求的参数里id没做归属校验改个数字就能操作别人的数据。这类问题纯靠关键词搜不出来必须按业务模块读逻辑对照“谁能做什么”画权限矩阵。3.7 SSRF 与 XXE外连请求里的隐形口子SSRF 出现在“服务端替我发请求”的功能里图片抓取、URL 预览、Webhook、远程导入、健康检查。$url $_POST[url]; $ch curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $body curl_exec($ch);这段代码没限制协议和内网地址。攻击者可以让服务端去请求内网的管理接口、云环境的元数据地址或者用file://读本地文件curl 在某些编译选项下支持。修复需要做三件事限制协议为http、https解析域名后检查 IP 是否落在内网段禁止自动跟随跳转否则会被 302 绕到内网。$parts parse_url($url); if (!in_array($parts[scheme] ?? , [http, https], true)) { exit(bad scheme); } $ip gethostbyname($parts[host]); if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) false) { exit(bad host); }注意 DNS 重绑定问题校验时的 IP 和实际请求时的 IP 可能不同。稳妥的做法是解析后把 IP 固定下来请求时直接用 IP 加 Host 头或者自己实现请求而不依赖自动解析。XXE 出现在解析 XML 的地方PHP 里常见于simplexml_load_string、DOMDocument::loadXML。在老版本PHP 8 之前libxml 默认会加载外部实体一份构造好的 XML 就能读本地文件甚至做 SSRF。PHP 8 之后默认不再加载外部实体libxml_disable_entity_loader也已被废弃但老项目依然要防。$xml simplexml_load_string($input, SimpleXMLElement, LIBXML_NOENT | LIBXML_DTDLOAD);上面这段显式开启了实体加载属于高危写法。审计时搜LIBXML_NOENT、LIBXML_DTDLOAD、libxml_disable_entity_loader(false)以及任何用户可控的 XML 输入。4. 一次完整的实操过程记录4.1 环境准备把版本对齐这一步经常被跳过但它直接决定了后面的结论准不准。我的做法是从composer.json的require段找 PHP 版本约束从部署脚本或文档找实际运行版本从composer.lock找依赖版本。三者对不上就以最老的为准做验证因为老版本往往引入更多可利用条件。容器环境里我一般准备两套一套是项目声明的版本一套是项目声明的最低版本。同一段代码在两套环境里各跑一遍能快速区分“理论漏洞”和“实际可利用”。数据库用模拟数据灌进去表结构和真实一致但内容全是假的。Web 服务器配置要按生产来尤其是上传目录是否可执行、是否开启伪静态这些直接影响利用路径。PHP 配置里我会特别关注几项display_errors开发时打开方便看报错验证时注意别把敏感信息带出去、open_basedir生产应设置、allow_url_include应关闭、disable_functions生产建议禁用一批命令执行函数、session.cookie_httponly和session.cookie_samesite影响会话相关漏洞的利用。把这些配置抄成一份清单每次审计新项目都对照一遍。4.2 第一轮扫描关键词与 AST第一轮我追求的是“快而全”不追求准确。第一步用全文搜索把危险函数全部捞出来输出成“文件:行号:内容”的列表。搜索时注意正则要覆盖变体比如system要写成\b(system|exec|shell_exec|passthru|popen|proc_open)\s*\(避免漏掉大小写和空格变体。第二步用静态分析工具做辅助。基于抽象语法树的工具能识别变量传播比纯正则准得多但会有大量误报。我把误报率控制在“能用”的程度只看工具报出的“路径完整”的条目路径断掉的先放一边。这一轮的产出是一份几十到几百条的候选列表。第三步做人工筛选。按 2.3 的分层表排序极高危和高危先看中危抽样看。筛选标准就是 1.2 讲的三个要素可控、可达、无有效过滤。这个阶段我大概能筛掉七成噪音。4.3 第二轮精读还原调用链对筛出来的候选点逐个做完整回溯。以一处文件写入为例流程大致是这样先看写入的文件名从哪来往上找赋值发现来自一个方法参数就找谁调用了这个方法调用方传的是控制器里的变量再看这个变量来自哪个请求参数中间如果经过了工具类的方法就把工具类的方法体也读一遍确认有没有过滤。这条链上任何一环出现“白名单”“类型强转”“路径规范化后前缀校验”就判定为断。如果没有继续往上追到请求参数为止。追完之后把整条链写成文字记录格式是“参数名 - 文件:行号 - 函数 - 文件:行号 - 汇点”。这份记录既是给自己看的也是后面写报告的基础。这一步最耗时间一个中等复杂度的洞可能要花一两个小时。但它是整个审计里价值最高的部分因为只有走完全程你才知道这个点是不是真的能打。4.4 动态验证从断点到日志静态分析给出的结论必须动态验证否则报告里写的东西经不起开发追问。验证的第一步是打日志。在最靠近汇点的位置临时插一行把变量内容写进日志文件然后构造请求看日志里出现的是什么。这一步能快速确认“数据到底有没有流到这里”“中间被改成了什么样”。日志要写在测试环境验证完立刻删掉。第二步是断点调试。配置好调试扩展在关键行下断点看变量值、调用栈、包含的文件。调试器最大的好处是能看到“运行时才确定”的东西比如动态类名、call_user_func的实际目标、include的实际路径。第三步是构造最小载荷。我习惯从最温和的验证开始SQL 注入先用 AND 11--和 AND 12--对比返回差异命令执行先用echo或者写文件这种可观测但破坏性小的动作文件读取先读一个自己放进去的测试文件。确认通道存在之后再评估危害程度不在测试环境里跑破坏性载荷。第四步是记录证据。每个验证步骤都要留下请求、响应、日志片段报告里附上关键截图或文本。没有证据的漏洞描述在开发眼里等于没说。4.5 报告怎么写才有人愿意改技术再硬报告写得烂也没人改。我总结的格式是四段式位置、成因、复现、修复。位置要精确到文件和行号附上关键代码片段。成因不要写“没有过滤用户输入”这种空话要写清楚“第 42 行的$order直接拼进 ORDER BY 子句未做白名单校验导致结构位注入”。复现要给完整的请求样例包括方法、路径、参数、必要的请求头和 Cookie让别人照着敲一遍就能看到结果。修复要给可直接粘贴的代码而不是“建议使用预处理语句”这种指导性文字。还有一个细节按危害排序把能直接拿权限的放最前面。开发的时间有限你要确保他们先修最要命的。同一类问题如果出现多次合并成一条并列出所有位置不要拆成二十条重复内容。5. 常见问题与排查技巧实录5.1 调用链追丢了怎么办这是最高频的问题。追到某个方法里变量突然“消失”了或者变成了一个看不出出处的属性。第一个技巧是从汇点倒着追。正向追丢了就回到汇点看这个变量名在方法内还有哪些赋值点逐个往回找。倒推往往比正推更容易因为汇点附近的变量名通常更有语义。第二个技巧是搜变量名的所有出现。同名变量在不同作用域里可能是不同的东西但至少能给你线索。特别是类属性$this-db、$this-config这类全局搜一遍就能找到定义和所有使用点。第三个技巧是看构造函数和初始化方法。很多属性是在__construct或者init里赋值的追到属性就去看初始化。第四个技巧是接受“追不到”。有些链确实断在框架内部或者扩展里这时候不要硬追改为动态验证直接构造请求在汇点打日志看实际值。静态追不动就上动态这是效率最高的切换。5.2 框架封装带来的误报用框架的项目静态工具会报出一大堆误报因为工具看不懂框架的封装。比如查询构造器$this-db-where(id, $id)-find()工具看到where就报 SQL 注入实际上第二个参数走的是绑定。判断方法是去看框架的where实现确认它是不是把值做了参数绑定。再比如模板引擎{$name}看着像直接输出实际上引擎默认开了自动转义。判断方法是找到模板编译后的缓存文件看最终生成的 PHP 代码里有没有htmlspecialchars。处理框架误报的通用方法是先读框架的核心类再读业务代码。花两个小时把框架的数据库层、模板层、请求层、路由层读一遍后面的判断效率会提升好几倍。这一步很多人嫌麻烦跳过结果就是被误报牵着走。5.3 过滤函数的绕过与误判看到过滤函数不要立刻判定“安全”要确认三件事过滤的对象对不对、过滤的时机对不对、过滤的强度够不够。对象不对的典型例子是用htmlspecialchars防 SQL 注入用addslashes防 XSS。时机不对的典型是先过滤再拼接、拼接后又解码。强度不够的典型是正则只匹配了小写、只匹配了一次可以双写绕过、只过滤了$_GET没过滤$_POST。还有一个反向问题误判为有过滤。有些函数名字看着像过滤实际不是。trim只去空白strip_tags去 HTML 标签但对属性里的注入无效mysql_real_escape_string依赖当前连接的字符集字符集设置不当比如 GBK时存在宽字节绕过。审计时看到这类函数一定要查文档确认它的确切语义而不是凭名字猜。5.4 常见问题速查表现象可能原因排查动作参数看着可控但打不进去前面有类型转换或白名单全文搜该参数名找所有赋值点静态工具报了一堆实际都打不通框架封装或全局过滤先读框架核心层再回来判断SQL 注入了但读不出数据权限受限、盲注、字段数不匹配改用时间盲注或报错注入验证通道文件包含包含成功但没执行包含的是非 PHP 内容或路径不对检查实际包含路径与文件内容反序列化构造不出来魔术方法链不完整或类被过滤列出所有魔术方法画关系图上传成功但访问不到上传目录不可访问或被重命名检查目录权限、命名规则、Web 配置命令执行没回显函数被禁用或输出被吞改用写文件验证检查disable_functions会话相关漏洞打不通Cookie 属性限制检查HttpOnly、SameSite、Secure配置这张表是我自己贴在工作区墙上的遇到卡壳就对着过一遍大部分问题能在十分钟内定位方向。6. 把审计做快的几个习惯6.1 建立自己的敏感点笔记每审计一个项目我都会把新遇到的危险写法记下来形成一个持续增长的笔记。时间长了这份笔记比任何工具都好用因为它记录的是“真实项目里长什么样”而不是“理论上有什么函数”。笔记的分类大致是危险拼接入参、动态调用、路径处理、编码解码、鉴权判断、缓存与序列化。每条记录包含一段匿名化的代码片段和一句判断结论。积累到几百条之后看新项目时会产生很强的模式识别很多问题扫一眼就有预感。6.2 用最小复现脚本代替手工点页面验证阶段最浪费时间的动作是“打开浏览器、登录、点菜单、填表单”。我习惯为每个待验证的点写一个最小复现脚本用命令行直接发请求带好 Cookie 和必要参数。脚本只有几十行但能反复执行、方便改参数、方便对比。curl -s -X POST http://127.0.0.1:8080/search.php \ -H Cookie: PHPSESSIDtest123 \ --data-urlencode kw% OR 11 \ -o /tmp/resp1.html配合两个请求的响应对比很多判断几秒钟就能完成。这个习惯看起来只是省了几次点击实际省下的是注意力的切换成本——你不需要在浏览器和编辑器之间来回跳思路能一直保持连贯。6.3 复盘把每个漏洞还原成一句“如果”每个项目审计完之后我会花半小时做复盘把每个确认的漏洞压缩成一句“如果当初这样写就不会有问题”。这句话不是给开发看的是给自己看的。比如“如果$order走了白名单映射这个结构位注入就不存在”“如果上传目录禁用了脚本执行即使扩展名校验被绕过也拿不到代码执行”“如果反序列化加了allowed_classes白名单这条魔术方法链就断在第一步”。把这些“如果”攒起来就是一套修复模式的清单。下次审计时看到同类写法你会立刻知道它最终会以什么形式出问题、修起来要动哪一层。这比记住一百个函数名有用得多。我在实际项目里最深的一个体会是审计的瓶颈从来不是工具而是对“这条数据到底能不能被控制”的判断力。工具能帮你把范围缩小到几十个点剩下的判断全靠对业务逻辑和框架行为的理解。所以我的建议是前期多花时间读框架和读业务少花时间调工具参数验证阶段多用最小脚本少用手工点页面报告阶段多写可粘贴的修复代码少写指导性文字。这三条做到了一个中等规模项目的审计周期能从一个月压到一周左右。最后分享一个我一直在用的小技巧审计时准备一个空白的 Markdown 文件每读完一个目录就写三行总结——这个目录负责什么、有哪些入口、有哪些危险调用。写到第十个目录的时候你对整个项目的印象会非常清晰而且这份笔记可以直接变成报告的大纲。
做 PHP 源代码漏洞分析这些年踩过的坑比读过的代码行数还多。这篇东西不讲概念只讲实操拿到一套 PHP 项目源码怎么从入口文件一路追到危险函数怎么判断一条数据流是不是真的可控怎么把“看起来像漏洞”变成“能稳定复现的漏洞”。核心关键词是 PHP 源代码漏洞分析但我不打算把它写成一份教科书。它解决的问题很具体很多同学能跑通扫描器、能看懂别人的 writeup轮到自己面对几千个 PHP 文件时就不知道从哪个文件开始读、读到哪一行该停下来标记。如果你是会写 PHP 但没做过代码审计的开发或者是想从“会打靶”转到“会看源码”的安全爱好者又或者是要给自家老项目做一次安全体检的技术负责人下面的内容都能直接拿去用。我会按“想清楚—拆开看—动手跑—踩坑复盘”的顺序展开中间穿插大量模拟示例代码代码全部是示意片段不指向任何真实系统。1. 先搞清楚 PHP 源码审计到底在找什么1.1 运行模型决定了漏洞长相很多人一上手就去背敏感函数表这是本末倒置。PHP 的漏洞形态是被它的运行模型塑造出来的理解了模型函数表根本不用背。PHP 是“每次请求重新构建一遍世界”的语言脚本执行完进程里的变量、全局状态通常就清空了没有常驻内存的概念常驻的常驻进程模式是另一套玩法这里不展开。这意味着绝大多数漏洞是“单次请求内可完成”的类型参数拼进 SQL 就立刻查、参数拼进命令就立刻执行。这个模型还带来一个后果输入来源极其扁平。$_GET、$_POST、$_COOKIE、$_REQUEST、$_SERVER、php://input、上传的$_FILES基本就是全部的外部数据入口。你在审计时要做的事本质上就是枚举这些入口然后顺着赋值、传参、函数调用看这些数据最终流到了哪里。你不需要理解复杂的线程调度也不需要关心内存布局只要会追变量。反过来说PHP 项目里最危险的结构往往是“全局配置 自动加载”这套东西。很多老项目把数据库连接、路径配置、模板目录都塞进一个config.php然后各处include。这类文件读一遍你就能知道整个项目的数据会流向哪个数据库对象、哪个模板引擎、哪个文件目录。我在实际审计中读完入口和配置这两层对项目的危险面就已经有了七成把握。另一个常被忽略的点是版本。同样一段代码跑在 PHP 5.6 和 PHP 8.2 上可利用性可能完全不同。弱类型比较、反序列化行为、libxml 默认是否加载外部实体、preg_replace的/e修饰符这些差异直接决定了一个点能不能打。所以我在看任何项目之前第一件事是找composer.json、composer.lock、README、部署脚本里写的版本约束实在找不到就看代码里有没有用 PHP 8 才有的语法比如构造器属性提升、match表达式、命名参数用这个反推版本区间。1.2 审计的本质是追一条数据流把话说透代码审计找的不是“危险函数”而是“从可控输入到危险函数的完整路径”中间没有有效过滤。这条路径上的三个要素缺一不可。第一是可控性。参数确实来自用户而且攻击者能自由控制内容。有些字段看着是$_GET实际上前面被intval()转过或者只允许某几个枚举值那它就不算可控。第二是可达性。这段代码真的会被执行到吗大量历史遗留项目里有成片的死代码或者被废弃的控制器追了半天发现路由根本不会指向它。判断可达性靠的是路由配置、index.php里的分发逻辑、框架的自动路由规则。第三是过滤有效性。中间可能有addslashes、htmlspecialchars、白名单校验、正则匹配。你需要判断这些过滤针对的是不是当前这个汇点。htmlspecialchars对 XSS 有用对 SQL 注入基本没用addslashes在 GBK 编码下还有宽字节问题。这三个要素任意一个不成立这个点就不成立。我见过太多新手把“有可控变量”直接等同于“有漏洞”然后在报告里写一堆没法复现的东西最后被开发一句话打回来“这个参数前面转成整数了。”提示审计时养成一个习惯每标记一个疑似点就写下三行备注——输入从哪来、经过哪些函数、汇点是什么。写不出来这三行基本就是错觉。1.3 开始之前要划清的三条线动手之前必须把边界说清楚这不是形式主义是保护自己。第一条是授权线。只审计你拥有书面授权的代码。公司内部项目走内部流程开源项目按项目的安全披露政策来自己的练习项目随便折腾。没有授权就去翻别人的生产代码性质完全不同。第二条是环境线。绝对不要在真实生产环境上做验证。用隔离的容器或者虚拟机跑一份代码副本数据库用模拟数据网络出口做限制。反序列化、命令执行这类验证一旦溢出后果不可控。第三条是数据线。验证用的数据全部自己构造不要把真实用户数据导进测试环境。涉及敏感信息的字段在报告里做脱敏处理。这三条线画清楚之后剩下的就是纯技术活。我个人的习惯是先花半天时间只读不写把所有 PHP 文件列出来按目录结构过一遍标记出控制器、模型、公共库、第三方依赖四个大类。这一步看着慢实际能省下后面几倍的返工时间。2. 整体思路与拆解从入口到汇点怎么走2.1 先画地图别急着读代码面对一个几千文件的项目最容易犯的错是从第一个文件开始顺序读。读到第三百个文件的时候你已经忘了第一个文件里有什么。正确做法是先画地图。地图分三层。第一层是入口index.php、admin.php、api.php这类直接暴露给 Web 服务器的文件以及public/目录下的所有 PHP。用命令行的全文搜索扫一遍把根目录和入口目录下的文件列出来。第二层是分发入口文件里通常有一个路由表或者一段switch把?mxxxayyy映射到具体的类和方法。现代框架靠自动路由规则写在配置文件里老项目靠手写include。这一层决定了“哪些控制器能被我碰到”。第三层是公共设施数据库封装类、模板引擎、上传处理、文件读写工具类、日志类。这些是汇点最密集的地方也是复用最多的地方。一个公共的查询封装如果有问题可能一次性炸掉几十个接口。三层画完我会得到一张“输入到功能”的对照表。实际审计就从这张表里挑软柿子优先看文件上传、导入导出、模板渲染、参数多的搜索接口。这几类功能天然处理复杂输入出问题的概率最高。2.2 三条审计路线的取舍实际工作里我常用三条路线它们不是互斥的而是根据项目情况组合。路线一关键词驱动。用全文搜索直接搜危险函数eval、system、exec、shell_exec、popen、proc_open、assert、include、require、unserialize、extract、parse_str、call_user_func等等。搜出来之后逐个回溯变量来源。这条路线的优点是快十分钟就能摸清一个中型项目的危险面缺点是只能发现“显式调用”对框架封装、动态调用、链式调用的覆盖很差。路线二数据流驱动。从所有外部输入入口出发正向追踪。优点是不遗漏尤其擅长发现“参数绕了三层才到汇点”的情况缺点是非常耗时间一个有几百个接口的项目纯手工追完需要以周计。路线三功能驱动。按业务功能模块切一个模块一个模块地读完整逻辑。优点是能发现业务逻辑漏洞比如越权、支付金额篡改、验证码复用这类问题用关键词和数据流都很难自动发现缺点是效率最低且高度依赖你对业务的理解。我的实际组合是先用路线一快速摸底产出一份“高危文件清单”再用路线三挑清单里的重点模块精读最后用路线二对精读中发现的每一个可控点做完整回溯确认可达性和过滤。三轮下来覆盖率和效率的平衡基本能接受。2.3 敏感函数清单要按危险等级分层函数清单不能平铺必须分层否则你会被几十个echo淹死。危险等级典型函数或语法直接后果审计权重极高eval、assert字符串模式、create_function、preg_replace带/e任意代码执行每处必看高system、exec、shell_exec、passthru、popen、proc_open、反引号命令执行每处必看高unserialize、include/require带变量、file_put_contents带变量反序列化利用、任意文件包含、任意写入每处必看中高mysql_query/mysqli_query/PDO::query带拼接、-where()带原始字符串SQL 注入结合参数化情况看中file_get_contents、curl_exec、fsockopen带用户 URLSSRF、任意文件读取看 URL 来源与协议限制中header、setcookie带用户输入、模板输出未转义响应头注入、XSS看输出上下文低echo、print、var_dump信息泄露只关注敏感信息分层之后审计顺序就明确了先把“极高”和“高”全部过一遍这部分通常只占代码量的百分之几但覆盖了大部分能直接拿 shell 的问题。然后再处理“中高”和“中”这部分量大需要结合业务判断。还有一个容易漏的类别动态调用。$func($arg)、call_user_func、call_user_func_array、array_map、usort的回调参数、$$var可变变量。这类写法在框架里到处都是用关键词搜函数名搜不出来只能靠通读代码时留意。我个人的经验是看到$后面直接跟变量名再跟括号立刻停下来看这个变量能不能被外部影响。2.4 手工污点分析的四个动作真正落到每一行代码上污点分析其实就是四个反复执行的动作。动作一标记源。看到$_GET、$_POST、$_COOKIE、$_REQUEST、$_FILES、$_SERVER[HTTP_*]、php://input立刻在变量上打一个“脏”标记。同时注意别名$input array_merge($_GET, $_POST)之后$input里所有元素都是脏的。动作二跟随传播。赋值、拼接、数组操作、函数传参、返回值脏标记跟着走。这里有个高频陷阱脏数据经过explode、json_decode、base64_decode之后很多人下意识觉得“处理过了应该安全”实际上脏标记一点没少反而多了一层编码绕过。动作三检查净化。遇到类型转换intval、(int)、floatval、白名单比较、in_array带true、正则全匹配、hash_equals、password_verify可以视为该路径被切断。但要逐个确认净化是否真的覆盖了目标汇点的语义比如intval对 SQL 注入有效对文件路径就完全无效。动作四到达汇点判定。脏数据进入危险函数时逐个判定这里的上下文是什么拼接方式是什么有没有二次转义能不能构造出有效载荷这四个动作说起来简单实际执行时最大的难点是“跨文件”。脏数据传进一个方法方法内部又调了另一个类的静态方法静态方法里再拼进 SQL。这条链可能要跨五六个文件中间还有接口和多态。我的做法是用纸笔或者纯文本笔记画出调用链每跨一层就记一行“文件:行号 - 函数名”追丢了就回到最后一个确认点重来。3. 高频漏洞类型的逐个拆解与验证姿势3.1 SQL 注入拼接和参数化的那条细线PHP 项目里 SQL 注入依然是最常见的洞原因很简单预处理只解决“值”不解决“结构”。看这段模拟代码$keyword $_GET[kw] ?? ; $order $_GET[order] ?? id; $sql SELECT id, title FROM article WHERE title LIKE %{$keyword}% ORDER BY {$order} DESC; $rows $pdo-query($sql)-fetchAll();$keyword拼进了 LIKE 的字符串里虽然外面有引号但攻击者输入% OR 11之类的构造就能突破$order更直接完全没包裹属于典型的结构位注入。很多人看到项目用了 PDO 就放心了其实-query()直接执行拼接字符串和预处理一点关系都没有。正确姿势是所有“值”位置用占位符绑定所有“结构”位置表名、字段名、排序方向、LIMIT偏移用严格白名单。$allowOrder [id, created_at, views]; $order in_array($_GET[order] ?? , $allowOrder, true) ? $_GET[order] : id; $stmt $pdo-prepare(SELECT id, title FROM article WHERE title LIKE ? ORDER BY {$order} DESC); $stmt-execute([% . $keyword . %]);注意in_array第三个参数true这是严格比较少了它就会出现0 id这类历史遗留的松散匹配问题。审计时我重点看三类地方。一是ORDER BY、GROUP BY、LIMIT后面的变量这些位置预处理绑不了开发往往图省事直接拼。二是IN (...)子句很多人用implode拼数组如果数组元素没经过整数校验就是注入点。三是框架的“原生查询”方法比如某些 ORM 提供的whereRaw、-query()这些入口标注着“原样执行”是注入高发区。还有一个隐蔽点二次注入。用户提交的内容先被addslashes处理存进数据库取出来的时候斜杠已经没了再拼进新 SQL 就还原成了注入。验证这类问题必须走“写入—读取—再使用”的完整流程光看单点代码看不出来。3.2 文件包含与路径穿越点号与截断的老账文件包含的危害在于“包含即执行”。被包含的 PHP 文件里的代码会以当前上下文执行所以只要能控制包含路径哪怕只能包含一个上传的图片图片里藏 PHP 代码也可能直接拿到代码执行。$page $_GET[p] ?? home; include __DIR__ . /pages/ . $page . .php;这段代码的问题在于$page完全没过滤。攻击者可以构造../../uploads/avatar这类路径穿越也可以利用php://filter之类的流包装器读取源码。验证时我通常先试相对路径穿越再试流包装器最后试空字节和历史截断这些在现代版本已失效但老项目里偶尔还能撞上。修复的思路有三层。第一层是白名单只允许预定义的页面标识映射到固定文件。$map [home home.php, about about.php, help help.php]; $key $_GET[p] ?? home; if (!isset($map[$key])) { http_response_code(404); exit; } include __DIR__ . /pages/ . $map[$key];第二层是路径校验用realpath求出绝对路径再判断是否以允许的根目录开头。$base realpath(__DIR__ . /pages); $target realpath($base . / . $page . .php); if ($target false || strpos($target, $base . DIRECTORY_SEPARATOR) ! 0) { exit(invalid path); }要注意strpos的判断必须带后面的分隔符否则/pages_evil这种同前缀目录能绕过。第三层是配置兜底open_basedir限制 PHP 能访问的目录范围关闭allow_url_include现代版本默认关闭上传目录禁止执行 PHP。这三层是纵深防御缺一层都可能被绕过但全上之后攻击成本会高很多。路径穿越在“下载文件”“读取日志”“导出报表”功能里同样高发判断逻辑和包含完全一致只是汇点从include变成了readfile、file_get_contents。3.3 命令执行与代码执行最容易被低估的一类命令执行在 PHP 里通常出现在“系统工具调用”场景比如 ping 检测、图片处理、PDF 转换、压缩打包。看这段$host $_POST[host]; $out shell_exec(ping -c 1 . $host); echo pre{$out}/pre;直接拼 shell攻击者输入127.0.0.1; id就能执行任意命令。这类代码在运维工具、监控面板里非常普遍。有人会用escapeshellarg来修但这两个函数用错场景就没效果escapeshellarg($s)把整个字符串包成单个参数适合“一个参数就是一个值”的场景。escapeshellcmd($s)转义的是 shell 元字符但不保证参数边界两个叠加使用反而会出问题。更稳的做法是彻底不用 shell用proc_open传数组形式的参数PHP 7.4 起支持数组形式避免 shell 解析或者干脆用纯 PHP 实现功能。$cmd [ping, -c, 1, $host]; $proc proc_open($cmd, [1 [pipe, w], 2 [pipe, w]], $pipes);即便如此$host也必须先做格式校验比如只允许合法 IP 或域名正则否则参数注入依然存在。代码执行的核心是eval和assert。现代项目里直接写eval($_POST[x])的少了但间接的还有模板引擎的“沙箱逃逸”、表达式解析器、规则引擎、preg_replace的/e修饰符PHP 7 已移除只在老项目里出现、create_functionPHP 8 已移除。审计时看到“用户可以自定义公式/规则/表达式”的功能一定要重点看它怎么解析和执行。这里补一个判断技巧eval里的内容如果能通过外部输入控制哪怕一部分就是极高危。因为 PHP 代码执行不需要“构造完整语句”eval拼接一个分号就能插入任意逻辑不存在“只能执行表达式”的限制。3.4 反序列化魔术方法串起来的链反序列化漏洞的判定分两步先看有没有unserialize的入口再看有没有可用的魔术方法链。入口通常藏在“记住我”“偏好设置”“缓存”“队列消息”这些地方$pref $_COOKIE[pref] ?? ; if ($pref ! ) { $data unserialize(base64_decode($pref)); $theme $data[theme] ?? light; }这段的问题不只是“能不能控制对象”更在于unserialize遇到对象时会自动触发__wakeup、__destruct、__toString这些魔术方法。如果项目里存在一个类它的__destruct里做了“删除文件”“写日志”“发请求”这类动作而属性又是可控的就构成了一条利用链。审计反序列化的方法是“反向找”先把项目里所有定义了魔术方法的类列出来看每个魔术方法里做了什么危险动作属性是否来自对象字段再回到入口处看能不能构造出这个类的序列化字符串。这条链经常跨好几个类__toString触发另一个对象的__call__call里又调了某个工具类的__destruct。所以我在做反序列化审计时一定会画一张“类—魔术方法—危险动作”的关系图。修复思路很干脆能用json_decode就不要用unserialize必须用时加allowed_classes白名单。$data unserialize($raw, [allowed_classes [UserPref, ThemeConfig]]);注意allowed_classes false是完全禁止对象只保留数组和标量这是最安全的配置。另外序列化数据如果来自 Cookie 或表单一定要加签名校验否则攻击者可以随意篡改。3.5 文件上传不要相信浏览器给的类型上传功能几乎每个后台都有也是漏洞最集中的地方。最典型的错误写法if ($_FILES[file][type] image/png) { move_uploaded_file($_FILES[file][tmp_name], uploads/ . $_FILES[file][name]); }$_FILES[file][type]是客户端提交的Content-Type抓个包随便改。$_FILES[file][name]更是完全不可信攻击者可以传../../shell.php做路径穿越也可以传shell.php配合可执行的上传目录直接拿 shell。正确的校验顺序是先校验大小和数量再校验扩展名白名单再校验真实文件类型读文件头最后重命名并落到不可执行的目录。$allowExt [jpg, jpeg, png, gif, webp]; $ext strtolower(pathinfo($_FILES[file][name], PATHINFO_EXTENSION)); if (!in_array($ext, $allowExt, true)) { exit(bad ext); } $finfo new finfo(FILEINFO_MIME_TYPE); $mime $finfo-file($_FILES[file][tmp_name]); $allowMime [image/jpeg, image/png, image/gif, image/webp]; if (!in_array($mime, $allowMime, true)) { exit(bad mime); } $name bin2hex(random_bytes(16)) . . . $ext; $dest __DIR__ . /uploads/ . $name; move_uploaded_file($_FILES[file][tmp_name], $dest);几个细节值得展开。pathinfo取扩展名之后一定要strtolower否则.PHP能绕过白名单扩展名白名单比黑名单可靠得多黑名单永远漏phtml、phar、php5这些finfo读的是文件头比客户端声称的类型可靠重命名用随机串避免覆盖已有文件和路径穿越上传目录的 Web 服务器配置里必须禁止执行脚本。还有一个经常被忽略的风险Phar 反序列化。某些文件操作函数比如file_exists、getimagesize、filesize在接收phar://协议路径时会触发 Phar 元数据的反序列化。如果上传功能允许传 Phar 格式文件且路径可控就可能绕过“只能传图片”的限制触发反序列化链。审计时看到phar://或者用户可控路径传给文件函数要顺着这个方向查。3.6 弱类型、变量覆盖与鉴权绕过PHP 的松散比较是历史包袱很多鉴权逻辑栽在这上面。$token $_GET[token] ?? ; if ($token $user[token]) { /* 登录成功 */ }在老版本PHP 7 及以前0 abc结果为真因为字符串被转成了数字 0。如果$user[token]是哈希值还可能撞上0e开头的“魔术哈希”——两个不同字符串的 MD5 都以0e开头时比较会把它们都当成 0从而相等。PHP 8 修改了比较规则数字与字符串比较时会把数字转成字符串这类绕过在 8 上大多失效但老项目依然大量存在。正确的写法只有一种用hash_equals做恒定时间比较或者统一用做严格比较。if (hash_equals($user[token], $token)) { /* ok */ }变量覆盖是另一类老问题。extract($_GET)、parse_str($str)不带第二个参数、$$var这类写法都能让外部输入直接覆盖内部变量。最经典的利用是覆盖配置文件里的变量foreach ($_GET as $k $v) { $$k $v; } // 后面某处 if ($isAdmin) { /* 管理操作 */ }攻击者传?isAdmin1就提权了。这类代码在现代项目里少见但老系统和一些“模板参数注入”场景仍然存在。审计时搜extract、parse_str、$$再看作用域里有没有关键布尔变量。鉴权绕过还有一类是逻辑层面的接口只在前端做了按钮隐藏后端接口没校验角色或者校验用$_REQUEST而攻击者可以用不同位置的参数覆盖再或者删除请求的参数里id没做归属校验改个数字就能操作别人的数据。这类问题纯靠关键词搜不出来必须按业务模块读逻辑对照“谁能做什么”画权限矩阵。3.7 SSRF 与 XXE外连请求里的隐形口子SSRF 出现在“服务端替我发请求”的功能里图片抓取、URL 预览、Webhook、远程导入、健康检查。$url $_POST[url]; $ch curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $body curl_exec($ch);这段代码没限制协议和内网地址。攻击者可以让服务端去请求内网的管理接口、云环境的元数据地址或者用file://读本地文件curl 在某些编译选项下支持。修复需要做三件事限制协议为http、https解析域名后检查 IP 是否落在内网段禁止自动跟随跳转否则会被 302 绕到内网。$parts parse_url($url); if (!in_array($parts[scheme] ?? , [http, https], true)) { exit(bad scheme); } $ip gethostbyname($parts[host]); if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) false) { exit(bad host); }注意 DNS 重绑定问题校验时的 IP 和实际请求时的 IP 可能不同。稳妥的做法是解析后把 IP 固定下来请求时直接用 IP 加 Host 头或者自己实现请求而不依赖自动解析。XXE 出现在解析 XML 的地方PHP 里常见于simplexml_load_string、DOMDocument::loadXML。在老版本PHP 8 之前libxml 默认会加载外部实体一份构造好的 XML 就能读本地文件甚至做 SSRF。PHP 8 之后默认不再加载外部实体libxml_disable_entity_loader也已被废弃但老项目依然要防。$xml simplexml_load_string($input, SimpleXMLElement, LIBXML_NOENT | LIBXML_DTDLOAD);上面这段显式开启了实体加载属于高危写法。审计时搜LIBXML_NOENT、LIBXML_DTDLOAD、libxml_disable_entity_loader(false)以及任何用户可控的 XML 输入。4. 一次完整的实操过程记录4.1 环境准备把版本对齐这一步经常被跳过但它直接决定了后面的结论准不准。我的做法是从composer.json的require段找 PHP 版本约束从部署脚本或文档找实际运行版本从composer.lock找依赖版本。三者对不上就以最老的为准做验证因为老版本往往引入更多可利用条件。容器环境里我一般准备两套一套是项目声明的版本一套是项目声明的最低版本。同一段代码在两套环境里各跑一遍能快速区分“理论漏洞”和“实际可利用”。数据库用模拟数据灌进去表结构和真实一致但内容全是假的。Web 服务器配置要按生产来尤其是上传目录是否可执行、是否开启伪静态这些直接影响利用路径。PHP 配置里我会特别关注几项display_errors开发时打开方便看报错验证时注意别把敏感信息带出去、open_basedir生产应设置、allow_url_include应关闭、disable_functions生产建议禁用一批命令执行函数、session.cookie_httponly和session.cookie_samesite影响会话相关漏洞的利用。把这些配置抄成一份清单每次审计新项目都对照一遍。4.2 第一轮扫描关键词与 AST第一轮我追求的是“快而全”不追求准确。第一步用全文搜索把危险函数全部捞出来输出成“文件:行号:内容”的列表。搜索时注意正则要覆盖变体比如system要写成\b(system|exec|shell_exec|passthru|popen|proc_open)\s*\(避免漏掉大小写和空格变体。第二步用静态分析工具做辅助。基于抽象语法树的工具能识别变量传播比纯正则准得多但会有大量误报。我把误报率控制在“能用”的程度只看工具报出的“路径完整”的条目路径断掉的先放一边。这一轮的产出是一份几十到几百条的候选列表。第三步做人工筛选。按 2.3 的分层表排序极高危和高危先看中危抽样看。筛选标准就是 1.2 讲的三个要素可控、可达、无有效过滤。这个阶段我大概能筛掉七成噪音。4.3 第二轮精读还原调用链对筛出来的候选点逐个做完整回溯。以一处文件写入为例流程大致是这样先看写入的文件名从哪来往上找赋值发现来自一个方法参数就找谁调用了这个方法调用方传的是控制器里的变量再看这个变量来自哪个请求参数中间如果经过了工具类的方法就把工具类的方法体也读一遍确认有没有过滤。这条链上任何一环出现“白名单”“类型强转”“路径规范化后前缀校验”就判定为断。如果没有继续往上追到请求参数为止。追完之后把整条链写成文字记录格式是“参数名 - 文件:行号 - 函数 - 文件:行号 - 汇点”。这份记录既是给自己看的也是后面写报告的基础。这一步最耗时间一个中等复杂度的洞可能要花一两个小时。但它是整个审计里价值最高的部分因为只有走完全程你才知道这个点是不是真的能打。4.4 动态验证从断点到日志静态分析给出的结论必须动态验证否则报告里写的东西经不起开发追问。验证的第一步是打日志。在最靠近汇点的位置临时插一行把变量内容写进日志文件然后构造请求看日志里出现的是什么。这一步能快速确认“数据到底有没有流到这里”“中间被改成了什么样”。日志要写在测试环境验证完立刻删掉。第二步是断点调试。配置好调试扩展在关键行下断点看变量值、调用栈、包含的文件。调试器最大的好处是能看到“运行时才确定”的东西比如动态类名、call_user_func的实际目标、include的实际路径。第三步是构造最小载荷。我习惯从最温和的验证开始SQL 注入先用 AND 11--和 AND 12--对比返回差异命令执行先用echo或者写文件这种可观测但破坏性小的动作文件读取先读一个自己放进去的测试文件。确认通道存在之后再评估危害程度不在测试环境里跑破坏性载荷。第四步是记录证据。每个验证步骤都要留下请求、响应、日志片段报告里附上关键截图或文本。没有证据的漏洞描述在开发眼里等于没说。4.5 报告怎么写才有人愿意改技术再硬报告写得烂也没人改。我总结的格式是四段式位置、成因、复现、修复。位置要精确到文件和行号附上关键代码片段。成因不要写“没有过滤用户输入”这种空话要写清楚“第 42 行的$order直接拼进 ORDER BY 子句未做白名单校验导致结构位注入”。复现要给完整的请求样例包括方法、路径、参数、必要的请求头和 Cookie让别人照着敲一遍就能看到结果。修复要给可直接粘贴的代码而不是“建议使用预处理语句”这种指导性文字。还有一个细节按危害排序把能直接拿权限的放最前面。开发的时间有限你要确保他们先修最要命的。同一类问题如果出现多次合并成一条并列出所有位置不要拆成二十条重复内容。5. 常见问题与排查技巧实录5.1 调用链追丢了怎么办这是最高频的问题。追到某个方法里变量突然“消失”了或者变成了一个看不出出处的属性。第一个技巧是从汇点倒着追。正向追丢了就回到汇点看这个变量名在方法内还有哪些赋值点逐个往回找。倒推往往比正推更容易因为汇点附近的变量名通常更有语义。第二个技巧是搜变量名的所有出现。同名变量在不同作用域里可能是不同的东西但至少能给你线索。特别是类属性$this-db、$this-config这类全局搜一遍就能找到定义和所有使用点。第三个技巧是看构造函数和初始化方法。很多属性是在__construct或者init里赋值的追到属性就去看初始化。第四个技巧是接受“追不到”。有些链确实断在框架内部或者扩展里这时候不要硬追改为动态验证直接构造请求在汇点打日志看实际值。静态追不动就上动态这是效率最高的切换。5.2 框架封装带来的误报用框架的项目静态工具会报出一大堆误报因为工具看不懂框架的封装。比如查询构造器$this-db-where(id, $id)-find()工具看到where就报 SQL 注入实际上第二个参数走的是绑定。判断方法是去看框架的where实现确认它是不是把值做了参数绑定。再比如模板引擎{$name}看着像直接输出实际上引擎默认开了自动转义。判断方法是找到模板编译后的缓存文件看最终生成的 PHP 代码里有没有htmlspecialchars。处理框架误报的通用方法是先读框架的核心类再读业务代码。花两个小时把框架的数据库层、模板层、请求层、路由层读一遍后面的判断效率会提升好几倍。这一步很多人嫌麻烦跳过结果就是被误报牵着走。5.3 过滤函数的绕过与误判看到过滤函数不要立刻判定“安全”要确认三件事过滤的对象对不对、过滤的时机对不对、过滤的强度够不够。对象不对的典型例子是用htmlspecialchars防 SQL 注入用addslashes防 XSS。时机不对的典型是先过滤再拼接、拼接后又解码。强度不够的典型是正则只匹配了小写、只匹配了一次可以双写绕过、只过滤了$_GET没过滤$_POST。还有一个反向问题误判为有过滤。有些函数名字看着像过滤实际不是。trim只去空白strip_tags去 HTML 标签但对属性里的注入无效mysql_real_escape_string依赖当前连接的字符集字符集设置不当比如 GBK时存在宽字节绕过。审计时看到这类函数一定要查文档确认它的确切语义而不是凭名字猜。5.4 常见问题速查表现象可能原因排查动作参数看着可控但打不进去前面有类型转换或白名单全文搜该参数名找所有赋值点静态工具报了一堆实际都打不通框架封装或全局过滤先读框架核心层再回来判断SQL 注入了但读不出数据权限受限、盲注、字段数不匹配改用时间盲注或报错注入验证通道文件包含包含成功但没执行包含的是非 PHP 内容或路径不对检查实际包含路径与文件内容反序列化构造不出来魔术方法链不完整或类被过滤列出所有魔术方法画关系图上传成功但访问不到上传目录不可访问或被重命名检查目录权限、命名规则、Web 配置命令执行没回显函数被禁用或输出被吞改用写文件验证检查disable_functions会话相关漏洞打不通Cookie 属性限制检查HttpOnly、SameSite、Secure配置这张表是我自己贴在工作区墙上的遇到卡壳就对着过一遍大部分问题能在十分钟内定位方向。6. 把审计做快的几个习惯6.1 建立自己的敏感点笔记每审计一个项目我都会把新遇到的危险写法记下来形成一个持续增长的笔记。时间长了这份笔记比任何工具都好用因为它记录的是“真实项目里长什么样”而不是“理论上有什么函数”。笔记的分类大致是危险拼接入参、动态调用、路径处理、编码解码、鉴权判断、缓存与序列化。每条记录包含一段匿名化的代码片段和一句判断结论。积累到几百条之后看新项目时会产生很强的模式识别很多问题扫一眼就有预感。6.2 用最小复现脚本代替手工点页面验证阶段最浪费时间的动作是“打开浏览器、登录、点菜单、填表单”。我习惯为每个待验证的点写一个最小复现脚本用命令行直接发请求带好 Cookie 和必要参数。脚本只有几十行但能反复执行、方便改参数、方便对比。curl -s -X POST http://127.0.0.1:8080/search.php \ -H Cookie: PHPSESSIDtest123 \ --data-urlencode kw% OR 11 \ -o /tmp/resp1.html配合两个请求的响应对比很多判断几秒钟就能完成。这个习惯看起来只是省了几次点击实际省下的是注意力的切换成本——你不需要在浏览器和编辑器之间来回跳思路能一直保持连贯。6.3 复盘把每个漏洞还原成一句“如果”每个项目审计完之后我会花半小时做复盘把每个确认的漏洞压缩成一句“如果当初这样写就不会有问题”。这句话不是给开发看的是给自己看的。比如“如果$order走了白名单映射这个结构位注入就不存在”“如果上传目录禁用了脚本执行即使扩展名校验被绕过也拿不到代码执行”“如果反序列化加了allowed_classes白名单这条魔术方法链就断在第一步”。把这些“如果”攒起来就是一套修复模式的清单。下次审计时看到同类写法你会立刻知道它最终会以什么形式出问题、修起来要动哪一层。这比记住一百个函数名有用得多。我在实际项目里最深的一个体会是审计的瓶颈从来不是工具而是对“这条数据到底能不能被控制”的判断力。工具能帮你把范围缩小到几十个点剩下的判断全靠对业务逻辑和框架行为的理解。所以我的建议是前期多花时间读框架和读业务少花时间调工具参数验证阶段多用最小脚本少用手工点页面报告阶段多写可粘贴的修复代码少写指导性文字。这三条做到了一个中等规模项目的审计周期能从一个月压到一周左右。最后分享一个我一直在用的小技巧审计时准备一个空白的 Markdown 文件每读完一个目录就写三行总结——这个目录负责什么、有哪些入口、有哪些危险调用。写到第十个目录的时候你对整个项目的印象会非常清晰而且这份笔记可以直接变成报告的大纲。
