代码执行漏洞的常用防护手段是什么

去年某电商平台因为一个图片处理接口没过滤参数，攻击者上传了一个带恶意代码的执行“图片”，服务器直接执行了里面的漏洞PHP，整个用户数据库被拖走。用防事后复盘，护手开发团队说“没想到他会传那种东西”。代码的常段这种“没想到”在代码执行漏洞里几乎是执行标配——漏洞本身往往不复杂，但造成的漏洞破坏力极强，因为攻击者一旦能让你的用防服务器跑他的代码，就等于拿到了最高权限。护手

防护的代码的常段核心思路其实就一句话：永远不要相信用户输入会乖乖当数据。但具体怎么做，执行得拆开来看。漏洞最基础也最容易被忽略的用防是输入验证。不是护手简单过滤几个引号就完事，而是明确你的程序期望什么格式，然后严格卡住。比如一个用户ID参数，只允许数字，那就用正则^[0-9]+$去匹配，不匹配直接拒绝。别用黑名单——黑名单永远漏，今天漏个${ }，明天漏个反引号。白名单才是正路。

再往上走一层，很多代码执行漏洞的入口是文件包含或者反序列化。PHP里include $_GET['page']这种写法，攻击者传个../../etc/passwd就能读文件，传个远程URL甚至能直接执行代码。防护手段是关掉allow_url_include，并且用绝对路径白名单来限定可包含的文件。Java的反序列化更麻烦，ObjectInputStream读进来的东西可能触发Runtime.exec()。现在主流做法是禁止反序列化不可信数据，或者用ObjectInputFilter做类白名单。我见过一个项目还在用老版本的Fastjson，结果被@type玩穿了，补丁打上之前服务器已经被人挖矿挖了三天。

有个细节值得注意：很多防护失败不是因为技术选型不对，而是因为开发图省事。比如明明可以用参数化查询，非要字符串拼接SQL；明明可以用ProcessBuilder传参数数组，非要用Runtime.exec()拼字符串。省一行代码，赔一个数据库。

命令执行漏洞的防护更直接。如果非要调用系统命令，别用shell解释器。Java里Runtime.exec(String)会走shell，Runtime.exec(String[])不会。Python里os.system会走shell，subprocess.run加shell=False就不会。能传数组就别传字符串，能指定绝对路径就别依赖PATH环境变量。我见过一个运维脚本用ping $host，攻击者传个; rm -rf /，结果整个服务器被清空。这种案例每年都在重演。

还有一层容易被忽视的是权限隔离。就算攻击者真的执行了代码，如果进程跑在低权限用户下，能造成的破坏也有限。Docker容器里跑应用，加上--read-only和--cap-drop=ALL，代码执行漏洞的杀伤力会小很多。但现实是，很多服务直接用root跑，一个system()调用就能改系统文件。我自己的习惯是，任何对外服务都单独建一个用户，/bin/false当shell，目录权限只给读写必要路径。

最后说一个反直觉的点：日志和监控比防护本身还重要。你不可能挡住所有攻击，但如果你能在攻击者执行whoami的时候收到告警，就能在数据被拖走之前掐断。用auditd监控execve系统调用，或者用eBPF抓异常进程创建，成本不高但效果立竿见影。我见过一个团队在服务器上装了falco，结果发现某个Web进程半夜突然去读/etc/shadow，一查就是代码执行漏洞被利用了。没有这个监控，他们可能几个月都不知道。

防护手段说到底就这些：白名单输入、参数化接口、禁用危险函数、最小权限、加上监控。每一条都不新鲜，但组合起来能挡住九成以上的实际攻击。剩下的那一成，靠的是及时打补丁和别写太离谱的代码。安全这件事，没有银弹，只有一层一层地加锁。