2017年9月，注入美国三大信用局之一的类漏Equifax被曝出数据泄露，1.43亿用户的注入社保号、驾照号、类漏信用卡信息被拖走。注入事后调查发现，类漏罪魁祸首是注入Apache Struts框架的一个漏洞——攻击者往HTTP请求头里塞了一段精心构造的“命令”，服务器就乖乖执行了。类漏这玩意儿不叫“黑客入侵”，注入它有个更精准的类漏名字：注入类漏洞。

注入的注入本质特别简单，就一句话：你把用户输入当成了代码来执行。类漏程序本来设计成“数据”和“指令”分得清清楚楚，注入但某些粗心的类漏写法，让数据混进了指令的注入跑道。就像你把一句话递给传话员，传话员却把你说的每个字都当成圣旨去执行——哪怕你只是在开玩笑说“把门拆了”。

最常见的注入是SQL注入。早年很多网站后台拼查询语句是这么干的：SELECT * FROM users WHERE name = '“ + 用户输入 + “'。用户要是老老实实输入“张三”，没问题。但如果输入的是张三' OR '1'='1，整条语句就变成了SELECT * FROM users WHERE name = '张三' OR '1'='1'，条件恒真，于是攻击者轻松拿到全表数据。更狠的还能用; DROP TABLE users; --直接把表删了。这种漏洞在2000年代泛滥成灾，现在老系统里依然存在——我去年还帮朋友排查过一个企业内网系统，登录框输个单引号直接报数据库错误，明摆着是裸拼SQL。

注入不止打在数据库上。操作系统命令注入，用户提交的文件名被拼进system()函数，攻击者用分号追加whoami或rm -rf /就能控制服务器。还有LDAP注入、XPath注入、模板注入——凡是存在“拼接”的地方，都可能是入口。2019年爆出的SSTI（服务端模板注入）让不少Python和Java网站栽了跟头，攻击者输入${ 7*7}，如果页面返回49，说明模板引擎把用户输入当成了表达式执行，接下来就能构造更深的payload读取服务器文件。

防御手段其实老早就成熟了。最核心的一条叫“参数化查询”，也就是把SQL语句的骨架和用户数据分开传，数据库只把输入当值处理，永远不当代码执行。Java的PreparedStatement、Python的cursor.execute带占位符，都是干这个的。另一条是“输入验证”，严格白名单校验，只允许合法字符集通过。再深一层是“最小权限”——数据库账号别给DROP权限，Web服务别用root跑，就算被注入，伤害也被限制住。

但漏洞还是年年爆。为什么？因为人总图省事。框架的ORM帮你挡住了大部分注入，可总有人图方便写原生SQL；安全工具扫描过一遍，可总有新写的接口忘了加过滤器。更现实的是，很多老系统已经没人维护，代码烂在那里，像埋在地下的雷。

我见过最讽刺的案例：某公司花了上百万买安全设备，IPS、WAF、态势感知一应俱全，结果研发在代码里写了个调试接口，直接用拼接方式执行Redis命令——WAF看不见内网流量，攻击者从公网打进来，绕了一圈，最后靠这个接口把缓存里所有session key捞走了。设备再好，架不住代码里开着后门。

注入类漏洞的可怕之处在于它不挑语言、不挑框架，只挑人的习惯。只要有人还在用字符串拼接构造查询，它就永远存在。破解方法也不玄乎——写代码时多花十秒钟用占位符，上线上线前跑一遍自动化扫描，别把用户输入当上帝供着。但这十秒钟，恰恰是绝大多数开发最吝啬的。