2017年11月，代码Equifax公司数据库被攻破，注入1.43亿美国人的攻击社保号、驾照号、代码信用卡信息被拖走。注入事后调查发现，攻击攻击者利用的代码只是一个不起眼的Apache Struts框架漏洞——攻击者往一个表单字段里塞了一段精心构造的字符串，服务器就把不该执行的注入代码执行了。这，攻击就是代码代码注入攻击。

代码注入的注入本质，是攻击攻击者把恶意代码“混进”了程序原本要处理的数据里。程序分不清哪些是代码数据、哪些是注入命令，稀里糊涂地把攻击者的攻击代码当成了自己的指令来执行。SQL注入、命令注入、XSS、反序列化漏洞，统统是这个套路。你往输入框里打一句' OR '1'='1，数据库查询就变成了SELECT * FROM users WHERE name='' OR '1'='1'——永远为真，登录验证直接被你绕过去。

别觉得这玩意儿老掉牙。OWASP Top 10榜单上，注入攻击年年上榜，2021年依然排在第三位。我见过太多开发者的迷之自信：“我们用了参数化查询，不怕SQL注入。”然后转头就在动态排序功能里把列名直接拼进了SQL语句——因为参数化查询没法处理动态列名，他们图省事就手拼了。攻击者只要在排序参数里塞个IF(1=1,SLEEP(5),0)，就能让数据库卡上五秒。你防住了入口，人家从窗户爬进来。

代码注入真正可怕的地方在于，它攻击的是“信任边界”。程序信任了用户输入，信任了第三方接口返回的数据，信任了配置文件里的内容。一旦这些数据源被污染，整个执行链条就崩了。有个真实案例：某电商平台的搜索功能，用户输入商品关键词后，后台会把关键词拼进一个shell命令去调用搜索引擎。攻击者输入iphone; cat /etc/passwd，服务器就把自己的用户列表吐了出来。这不是段子，是我朋友公司真实发生过的事。

防御思路其实就一句话：永远不要相信外部输入。具体操作上，第一选择是使用安全的API——参数化查询、预编译语句、白名单校验，这些是正路。但更重要的一层，是给代码执行环境“上锁”。比如数据库账号只给最小权限，就算被注入了，攻击者也拿不到敏感表；再比如Linux系统里用seccomp限制进程能执行的系统调用，命令注入就算成功，也跑不了危险指令。

还有个经常被忽略的点：代码注入不只是外部攻击者的专利。内部人员如果能在配置中心或者环境变量里动手脚，一样能搞出注入攻击。我见过一个运维因为对主管不满，往配置文件的JAVA_OPTS里加了段-javaagent参数指向恶意jar包，应用启动时就把监控钩子装上了。这种内部威胁，比外部攻击更难防。

说到底，代码注入攻击拼的不是技术高低，而是谁更细心。攻击者每天都在翻你的输入框、URL参数、HTTP头、文件上传点，找那个你没过滤干净的角落。你多写一行校验代码，多配置一个安全策略，可能就堵住了一个坑。别等到Equifax那种级别的数据泄露发生，才想起来补漏洞——到那时候，你的用户数据可能已经在暗网上挂了三个月了。