代码注入漏洞

2017年，代码Equifax泄露了1.47亿人的注入信用数据。事后复盘，漏洞攻击者用的代码不是什么零日漏洞，而是注入一个两年前就公开披露、官方补丁早已发布的漏洞Apache Struts漏洞。问题出在哪？代码他们没打补丁。但更值得琢磨的注入是另一个层面——攻击者通过这个漏洞注入的代码，让服务器乖乖把数据库里的漏洞东西吐了出来。

代码注入的代码核心逻辑就一句话：让程序把你输入的东西当成代码来执行。正常情况，注入用户输入是漏洞数据，代码是代码代码，两者泾渭分明。注入注入攻击干的漏洞事，就是模糊这条边界。

拿SQL注入举例。一个登录页面，后台SQL可能是SELECT * FROM users WHERE username = '输入' AND password = '输入'。你在用户名框里填' OR '1'='1，SQL语句就变成了SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''。条件永远为真，直接绕过登录。这招在2000年代初的网站上几乎百试百灵，现在虽然少了，但换个马甲照样出现——比如某个电商平台的搜索接口没做好参数化查询，攻击者照样能拖库。

命令注入更直接。假设一个网站提供ping工具，后台执行ping -c 4 用户输入的IP。你输入127.0.0.1; cat /etc/passwd，分号让shell把后面的命令也执行了。服务器上的密码文件就这么被读出来了。我之前见过一个物联网设备的管理后台，固件升级接口直接把文件名拼进tar命令，攻击者上传一个名字里带反引号的文件，就能以root权限跑任意命令。这类设备往往没有WAF，也没有人盯着日志，被拿下了都不知道。

XSS算不算代码注入？广义上算。它注入的是JavaScript，执行环境从服务器变成了浏览器。存储型XSS尤其阴——攻击者把恶意脚本存进数据库，每个访问该页面的用户都会中招。MySpace早年有个著名的Samy蠕虫，就是靠XSS在用户之间疯狂传播，一天内感染了上百万账号。现代前端框架默认做了转义，但一旦开发者用dangerouslySetInnerHTML或者v-html，门就又打开了。

防御思路其实不复杂。参数化查询把数据和代码彻底分开，这是对付SQL注入最有效的手段。命令执行时用白名单校验输入，或者干脆别让用户输入拼进命令里。输出编码能挡住大部分XSS。但现实是，开发进度一赶，这些措施就容易被跳过。我见过一个项目，所有SQL都用了参数化查询，唯独一个报表模块为了“灵活”用了字符串拼接，结果就这一个口子被人拖了全表。

还有个被低估的点：注入不限于传统Web。日志注入、HTTP头注入、甚至模板引擎注入，原理都一样。攻击者往User-Agent里塞换行符，就能伪造日志条目；往模板里传特殊payload，可能触发SSTI，直接RCE。这些场景往往不在常规安全测试的覆盖范围内。

说到底，代码注入漏洞的根源不是技术缺陷，是设计习惯。只要还有开发者觉得“用户不会那么干”，注入就永远有生存空间。Equifax没打补丁是懒，但那些写了拼接SQL的人，是真的不知道自己在干什么。