代码执行漏洞的下代行漏防护，本质上就是码执一场“输入信任”的博弈。攻击者想尽办法让服务器把数据当代码执行，常用防守方则要确保数据永远只是防护数据。这活儿没有银弹，手段但有几道常用的下代行漏防线确实扛得住实战。
最直接的码执招数，是常用**对输入做严格的类型和格式校验**。别偷懒，防护别只在前端用JS拦一下，手段后端必须重写一遍。下代行漏比如一个接口期望接收整数ID，码执那就必须用正则或者类型判断把它死死钉在整数的常用范围里——哪怕攻击者塞过来一段精心构造的 `1;system('cat /etc/passwd')`，类型校验直接让它连第一关都过不去。防护有个真实案例：某电商平台曾因为订单号参数没校验，手段被人拼上`|whoami`，结果服务器乖乖吐出了用户名。后来修复方式很简单，加一行`if (!preg_match('/^\d+$/', $orderId)) die('bad request');`，问题就没了。
但光靠输入过滤不够，因为业务本身可能需要接受“半结构化”数据。这时候**参数化查询（Prepared Statement）**就得上场了。它把SQL语句的结构和数据彻底分开，数据库先编译好语句框架，再把参数当纯文本塞进去，想注入？没门。这招对SQL注入几乎是降维打击。我见过不少老系统，代码里全是字符串拼接的SQL，后来重构时全局替换成PDO预处理，漏洞扫描直接清零。
接下来是**输出编码**，这招主要防反射型XSS和存储型XSS。原理很简单：用户输入的内容要显示在HTML里，那就得把`<`、`>`、`"`这些字符转义成`<`、`>`、`"`。别小看这一步，很多论坛被挂马就是因为在帖子标题里直接输出了未过滤的`