代码执行漏洞的下代行漏常用防护手段，说穿了就这几招

上周帮朋友排查一个WordPress插件漏洞，码执攻击者只靠一个没过滤的常用eval()就拿到了服务器权限。日志里躺着一长串base64解码后的防护命令，从whoami到cat /etc/passwd，手段最后还试图下载挖矿脚本。下代行漏这种场景在真实攻防中太常见了——代码执行漏洞（RCE）之所以危险，码执是常用因为它直接跳过了身份验证和权限检查，让攻击者像本地管理员一样操作你的防护系统。

第一道防线：输入验证不是手段选择题，是下代行漏必答题

所有能到达解释器（PHP、Python、码执JavaScript等）的常用输入都必须被当成敌人。别信什么“内部调用不用过滤”的防护鬼话——我见过最离谱的案例是某个后台管理功能把用户上传的文件名直接拼进system("mv ".$filename." /tmp/")，攻击者传个;rm -rf /就完事了。手段白名单校验是最靠谱的，比如只允许字母数字和下划线，长度也限制死。黑名单？那玩意儿跟筛子一样，总有漏网之鱼。

第二道防线：禁用危险函数，但别只靠它

很多人喜欢在php.ini里禁用eval()、system()、exec()，这确实能挡住大部分“脚本小子”。但高级攻击者会找替代品——比如preg_replace()配合/e修饰符（PHP 5.5之前版本），或者用assert()当后门。我见过一个真实案例，攻击者利用call_user_func()动态调用被禁用的函数，绕得干干净净。所以禁用函数只是辅助，核心还是得靠输入过滤和最小权限原则。

第三道防线：最小权限，让被攻破的代价最大化

假设你的代码已经能被执行了，那接下来拼的就是权限边界。如果Web服务以root身份运行，那漏洞直接等于机器沦陷。但如果你用低权限用户（比如www-data）跑服务，再配合chroot或容器隔离，攻击者即使拿到shell也动弹不得。我自己的服务器上，PHP-FPM跑在独立用户下，目录权限只给读写需要的那几个文件夹，连日志目录都是独立的。这样即使被写入webshell，也读不到其他站点的配置文件。

第四道防线：输出编码和上下文感知转义

很多人只盯着输入，忽略了输出侧也可能触发代码执行。比如把用户输入直接拼进JavaScript模板里，攻击者构造个";alert(1);//就能注入。这时候需要对输出做编码——在HTML上下文用htmlspecialchars，在SQL上下文用参数化查询，在shell命令里用escapeshellarg()。有个细节：不同位置的编码规则完全不一样，别想着一个函数通吃。我见过某开发者用addslashes()处理所有场景，结果在JSON输出里照样被绕过。

现实中的血泪教训：别信框架的“自动防护”

Laravel的Eloquent ORM默认参数化查询，确实防住了SQL注入，但如果你用了DB::raw()或者whereRaw()，那又回到裸奔状态。同样的道理，Spring Boot的Thymeleaf模板默认转义，但如果你手动标记th:utext，那XSS就来了。框架只是给你提供工具，不是给你上保险。我审计过不少项目，漏洞往往出现在开发者“觉得框架会帮我处理”的地方——比如把用户输入塞进Runtime.getRuntime().exec()之前，没人记得做校验。

最后说个反直觉的点：有时候过度防护反而制造新漏洞。比如你为了防路径遍历，把../替换成空字符串，结果攻击者用....//绕过——因为替换后变成了../。正确做法是正规化路径后检查是否在允许目录内，而不是靠字符串替换。防护手段得灵活组合，别死记硬背那几个函数名。代码执行漏洞的攻防，本质上就是看谁对语言特性和运行时机制理解得更深。