命令执行漏洞与代码执行漏洞的区别

一个真实的命令例子最能说明问题。某厂商的执行执行防火墙设备爆出漏洞，安全公告上写着“远程命令执行”。漏洞漏洞另一家厂商的代码的区WAF产品同一天发公告，说的命令是“存在代码执行漏洞”。两者都拿到了CVE编号，执行执行风险评级都是漏洞漏洞高危。但攻击者实际能做的代码的区事，差了十万八千里。命令

命令执行漏洞，执行执行本质上是漏洞漏洞操作系统层面的问题。攻击者输入的代码的区内容被拼接到系统命令里，比如拼进`ping`、命令`whoami`或者`cat`后面。执行执行你传一个`;id`进去，漏洞漏洞系统就真的去执行了`id`命令。这种漏洞直接和shell打交道，权限通常继承自web服务进程。拿到的是系统用户权限，能干的事包括读文件、写文件、弹shell、横向移动。最典型的场景是Java的`Runtime.exec()`或者PHP的`system()`函数没过滤参数。

代码执行漏洞则是应用层的事。攻击者的输入被当作程序代码的一部分解析执行，但执行环境是语言运行时，不是操作系统。比如PHP的`eval()`函数接收了用户可控的字符串，或者Python的`exec()`、JavaScript的`Function()`构造函数。这里执行的是脚本语言代码，能调用语言提供的函数库，但默认碰不到系统底层。想执行系统命令，还得靠代码里的`system()`、`shell_exec()`这类函数去“借道”。

两者的危害边界很模糊，但有个关键分水岭——权限模型。命令执行直接继承进程的系统权限，相当于攻击者拿到了一个操作系统的“半成品shell”。代码执行更像是在沙箱里写脚本，能操作应用数据、篡改业务逻辑，但真要动系统文件，得先找提权漏洞配合。我见过一个代码执行漏洞，攻击者反复调用`file_get_contents()`读取配置，折腾半天也只拿到数据库密码，因为PHP配置里禁用了`system()`。换成命令执行，同样条件下直接`cat /etc/shadow`就完事了。

实际渗透测试中，区分这两者意义重大。命令执行可以立刻尝试反弹shell，代码执行得先分析当前语言环境有哪些可用函数、是否开启了危险扩展。有些代码执行漏洞能通过`assert()`回调实现命令执行，有些则只能读写文件。修复思路也不同——命令执行要严格白名单校验参数，代码执行则要想办法禁用`eval`、`assert`这类动态执行函数。

一个有趣的细节是：很多报告把两者混着写。原因在于代码执行漏洞经常被利用来“升级”成命令执行。攻击者先找到`eval()`的注入点，然后传入`system('whoami')`，这时候漏洞性质就变了。但防御方如果只盯着命令执行的特征去修，很容易漏掉代码执行这个源头。反过来，代码执行漏洞如果只能调用语言内置函数，危害可能比命令执行小得多，但碰上ThinkPHP那种框架级RCE，直接就能写文件拿webshell。

一句话总结我的经验：看到命令执行，先想系统权限；看到代码执行，先理清语言环境能干什么。两者不是同一个维度的东西，但攻击链上经常手拉手出现。修漏洞时别只堵输出点，得从输入点开始层层过滤，否则换个编码方式或者拼接手法，漏洞又活了。