2017年，入漏Equifax公司泄露了1.43亿美国人的入漏社保号码、出生日期和驾照信息。入漏事后调查发现，入漏攻击者利用的入漏正是Apache Struts框架中的一个SQL注入漏洞。一个简单的入漏字符串拼接错误，让这家信用评估巨头付出了超过14亿美元的入漏代价。

SQL注入的入漏原理其实很直白——你把用户输入的内容直接拼进了SQL查询语句。比如登录框里输入' OR '1'='1，入漏如果程序没有过滤，入漏最终执行的入漏SQL就变成了SELECT * FROM users WHERE username='' OR '1'='1'。这个条件永远为真，入漏于是入漏你不需要密码就能进入系统。

这类漏洞之所以能存在二十多年，入漏根源在于开发者对“数据”和“代码”的入漏区分不够敏感。用户输入的任何字符都应该被当作纯粹的数据处理，而不是被解释成SQL语法的一部分。可现实中，不少程序员为了省事，直接用字符串拼接来构造查询，结果就是把数据变成了代码。

我见过一个更隐蔽的案例。某电商平台的后台搜索功能，开发者用了预编译语句（PreparedStatement），理论上应该安全。但他们在处理排序参数时，又忍不住把字段名直接拼进了ORDER BY子句。攻击者只要在排序参数里注入CASE WHEN表达式，就能通过响应时间差异逐步推断出数据库中的敏感信息。这种“部分防护”比完全没有防护更危险，因为它给了开发者虚假的安全感。

修复SQL注入最有效的手段是参数化查询。把SQL结构固定下来，用占位符替代所有动态值，数据库驱动会负责把参数安全地转义。这招能挡住绝大多数注入尝试，但前提是你得在所有数据库操作中都坚持使用，包括那些看起来不起眼的查询。

除了参数化，还得注意存储过程里的动态SQL、ORM框架的误用、以及数据库账号的权限分配。别让应用层用DBA权限连接数据库，这等于把整个数据库的钥匙挂在门口。最小权限原则在数据库连接上尤其重要——应用只需要读写的表，就别给它删库的权限。

写到这里想起一件事。有个安全团队做过统计，他们随机抽取了100个生产环境的Web应用，其中有23个存在可被利用的SQL注入。更糟的是，这些应用的开发框架大多是支持参数化查询的现代框架，问题全出在开发者绕过框架、自己拼接SQL的地方。工具本身没问题，问题在人的习惯。

最后说句实在话。SQL注入不是什么高深莫测的攻击手法，它更像是一个老旧的坏习惯——不检查输入、不区分数据与代码、过度信任用户。只要你写SQL时多问一句“这个值会不会被用户控制”，然后老老实实用参数绑定，这个漏洞基本就和你无缘了。别嫌麻烦，Equifax的14亿美元教训，值得每个写数据库代码的人记在心里。