2017年，代码的常段Equifax因为一个Apache Struts的执行远程代码执行漏洞，泄露了1.47亿人的漏洞敏感数据。事后调查发现，用防补丁其实早就发布了，护手但没人去装。代码的常段这个案例说明了一个残酷的执行事实：代码执行漏洞的防护，技术手段只是漏洞一半，另一半是用防人的执行力。

代码执行漏洞的护手本质是攻击者能让程序运行本不该运行的代码。PHP里的代码的常段eval($_GET['cmd'])、Java反序列化链、执行Python的漏洞pickle.loads()，都是用防经典入口。防护的护手核心思路只有一个：切断用户输入到代码执行之间的路径。但具体怎么做，每个层面都有讲究。

输入验证不是万能的，但不能没有

很多人觉得输入过滤很low，容易被绕过。确实，黑名单式的过滤基本等于自欺欺人——你永远想不到攻击者能用什么编码方式绕过。但白名单不一样。如果一个参数只应该是数字，那就强制转成整数；如果只应该是几个固定值之一，那就用枚举校验。这不是防注入的全部，但它能把大量低质量的攻击挡在门外。

我在实际项目里见过一个案例：某接口的sort参数直接拼进了SQL的ORDER BY子句。开发用了addslashes()，觉得万事大吉。结果攻击者用(case when(1=1) then id else name end)照样盲注。后来改成白名单映射——前端传1对应id，传2对应name——问题才真正解决。

参数化查询：最被低估的防护手段

SQL注入是代码执行漏洞里最常见的一类。Prepared Statement（参数化查询）从机制上把数据和指令分离了，这不是过滤，是结构性的隔离。Java的PreparedStatement、Python的cursor.execute("...%s", (param,))、PHP的PDO绑定，都是这个思路。

问题是，很多开发者用着ORM却还在拼SQL。比如MyBatis里写${ }而不是#{ }，前者是字符串替换，后者是参数绑定。一字之差，防护效果天壤之别。这种细节，代码审查时得盯死。

反序列化：能不用就不用

Java反序列化漏洞这几年简直是重灾区。WebLogic、Fastjson、Shiro，一个接一个。根本原因在于Java反序列化机制本身允许在反序列化过程中执行任意类的readObject()方法，攻击者可以构造利用链。

防护手段有几层：一是升级依赖库，Fastjson关掉autoType；二是用JEP 290的序列化过滤器，在JVM层面加白名单；三是最彻底的——不用Java原生序列化，改用JSON或Protobuf。我个人的判断是，如果新项目还在用ObjectInputStream做网络传输，那基本是在给自己埋雷。

WAF和RASP：兜底但别依赖

WAF（Web应用防火墙）能拦掉不少已知攻击模式，但它的位置决定了它只能看HTTP层。加密流量、分块传输、协议畸变，都能让WAF失效。RASP（运行时应用自我保护）更贴近应用，在函数调用层面做检测，效果更好，但性能开销和误报率是现实问题。

我的看法是：WAF和RASP是安全运营的最后一道防线，不是开发阶段偷懒的理由。如果代码本身写得千疮百孔，指望WAF兜住，迟早出事。

最小权限：被忽视的基础设施

就算攻击者真的执行了代码，如果运行环境的权限足够小，破坏力也有限。数据库账号只给必要的表权限，容器里不用root跑应用，PHP禁用exec、system等函数，这些措施单独看都不起眼，但组合起来能大幅压缩攻击面。

Equifax的教训里有一条：那个Struts漏洞本身需要上传恶意文件才能触发，但如果服务器目录权限配置合理，攻击者根本写不进去。安全是一个层层叠加的过程，没有哪一层是多余的。

代码执行漏洞的防护没有银弹。输入验证、参数化查询、反序列化管控、运行时防护、权限隔离，每一层都有它的位置。真正有效的做法是根据业务场景把这些手段组合起来，而不是指望某一个“最佳实践”解决所有问题。

(责任编辑：知识)