代码执行漏洞

一个不起眼的代码输入框，可能是执行攻击者撬开你整个系统的支点。

代码执行漏洞，漏洞说白了就是代码程序把用户输入的内容当成了代码来执行。这事儿听起来简单，执行但破坏力常常是漏洞灾难级的。2017年Equifax泄露1.4亿美国人社保信息，代码罪魁祸首就是执行Apache Struts框架里一个反序列化漏洞——攻击者往HTTP头里塞了段恶意数据，服务器就乖乖执行了远程命令。漏洞整个过程不用密码，代码不用绕过登录，执行一个请求就拿下内网权限。漏洞

这类漏洞的代码根源，往往是执行开发者对“数据”和“代码”的边界划得不够清。比如PHP里那个臭名昭著的漏洞eval()函数，你传进去的字符串会被当成PHP代码执行。有些老系统喜欢把用户提交的模板内容直接丢给eval()处理，图省事，结果就是攻击者提交system('rm -rf /')，服务器还真就照做了。

更隐蔽的是二次注入。数据先存进数据库，等下次调用时再拼接到危险函数里。举个例子，某个论坛允许用户设置昵称，后台用preg_replace()配合/e修饰符做关键词高亮。攻击者把昵称改成{ ${ eval($_POST[x])}}，第一次保存时数据库只当它是普通字符串，可等别的用户浏览帖子触发高亮功能，这段昵称就被当成PHP代码执行了。你查日志只能看到“正常”的数据库读写，根本想不到问题出在几个月前的一条用户资料。

修复这类漏洞，光靠过滤输入是堵不完的。真正管用的思路，是把“代码”和“数据”彻底隔离。比如用json_encode()而不是字符串拼接来传递参数，或者用白名单机制限制可执行的函数列表。我见过一个团队，把所有用户可控的输入都强制走专门的转义类，连数字类型都强制(int)转换，虽然代码丑了点，但两年没出过一起代码执行事故。

还有个经常被忽略的点——开发环境残留的后门。某次渗透测试，我通过一个测试接口的assert()调用直接拿到了服务器权限。那个接口是开发人员调试用的，上线时忘了删，参数名还叫debug。攻击者扫描目录就能发现这种接口，根本不需要什么高深技巧。

说句实在话，代码执行漏洞现在依然高发，不是因为技术多难防，而是很多团队根本没把“用户输入不可信”这条铁律当回事。框架自带的安全机制不用，非要自己造轮子；代码审查走过场，危险函数满天飞。等到被入侵了才急着打补丁，那已经是下下策了。