一个深夜，入漏某电商平台的洞危数据库被拖走，三百多万条用户记录连同密码哈希值躺在黑客的入漏硬盘里。事后排查发现，洞危漏洞入口不过是入漏一个搜索框——攻击者在参数里塞了句' OR '1'='1，数据库就把整张表吐了出来。洞危这不是入漏电影桥段，是洞危sql注入最典型的死法。

sql注入的入漏实质，是洞危攻击者把sql代码伪装成用户输入，骗过应用层直接操纵数据库。入漏你写查询语句时习惯用字符串拼接，洞危$sql = "SELECT * FROM users WHERE name = '" . $_GET['name'] . "'"，入漏那等于把数据库的洞危钥匙挂在门口。攻击者只要在输入框里输入' OR 1=1 --，入漏你的查询条件就形同虚设，所有行都成了合法结果。更狠的用UNION SELECT把其他表的数据捞出来，或者用INTO OUTFILE直接往服务器写webshell。

危害等级要分三层看。最浅的是数据泄露——用户名、手机号、身份证、订单记录，这些是黑市上的硬通货。中间层是权限提升，攻击者通过注入点执行UPDATE语句把自己的账户改成管理员，或者直接DROP TABLE把整个库清空，业务瘫痪是分分钟的事。最深层是服务器沦陷，如果数据库账户权限配得松，攻击者能借助xp_cmdshell这类存储过程执行系统命令，拿到操作系统的shell。到这一步，你的服务器就成了肉鸡，被拿去挖矿、发垃圾邮件、做跳板攻击别人。

我见过一个真实案例，某银行内部系统的报表查询功能，因为开发图省事，用拼接方式处理日期参数。攻击者绕过了防火墙和waf，通过时间盲注一点点把核心交易表的数据抽走，整个过程持续了三个月，银行毫无察觉。直到数据在黑市流通，才意识到出了问题。事后复盘，问题不在技术，在于开发人员根本没把用户输入当恶意代码看——他们默认数字参数就是数字，忘了sql注入的本质是"数据与代码的混淆"。

别以为用了参数化查询就万事大吉。存储过程里如果还藏着动态拼接，或者ORM框架处理某些特殊查询时退化成原生sql，照样有缝可钻。更别说那些老旧的系统，十几年前的代码还在跑，那时候的开发者根本没受过安全培训。我有次做渗透测试，遇到个政府网站，登录框直接报sql语法错误，错误信息把表名字段名全暴露了——这种系统能活到今天，纯粹靠运气。

修复其实不难，参数化查询是底线，输入验证是第二道门，数据库账户最小权限是第三道。难的是存量系统的改造——业务逻辑耦合在sql里，改起来牵一发动全身。但你不改，就是在赌攻击者永远找不到你那个不起眼的搜索框。赌注是你的数据、你的用户、你的业务连续性。

sql注入不是高深技艺，它是最基础的攻击手法之一，却年年出现在owasp top 10里。原因是它太容易发生了——只要开发者有一次偷懒，一次图省事，一次"应该没人会这么输入吧"的侥幸心理，漏洞就诞生了。技术对抗的本质，其实是人性对抗。