内容摘要：2015年，英国电信运营商TalkTalk被一个15岁少年用最基础的SQL注入攻破，156万用户数据泄露，公司股价一天蒸发四分之一。这不是什么高深攻击，就是往输入框里填了一段恶意SQL代码。 SQL注

2015年，危害英国电信运营商TalkTalk被一个15岁少年用最基础的危害SQL注入攻破，156万用户数据泄露，危害公司股价一天蒸发四分之一。危害这不是危害什么高深攻击，就是危害往输入框里填了一段恶意SQL代码。

SQL注入的危害本质，是危害应用程序把用户输入的数据当成了代码来执行。你打开一个登录页面，危害后端代码大概长这样：SELECT * FROM users WHERE username='$user' AND password='$pass'。危害正常输入没问题，危害但如果有人在用户名框里填 admin' --，危害这条SQL就变成了 SELECT * FROM users WHERE username='admin' --' AND password='...'。危害两个减号在SQL里是危害注释符，后面的危害密码验证直接被注释掉了。攻击者不需要知道密码，就能以admin身份登录。

这只是最表面的危害。拿到数据库权限之后能干的事，才是真正让人头疼的。

数据库里存的往往不只是账号密码。用户的身份证号、手机号、银行卡信息、家庭住址，全在一张张表里躺着。2011年索尼PSN被SQL注入攻破，7700万个账户的姓名、地址、邮箱、出生日期甚至信用卡信息全部泄露。索尼为此关闭PSN服务整整23天，直接损失估计1.7亿美元。一个注入点，赔进去的是一家公司几年的利润。

更狠的是，SQL注入能直接篡改数据。2017年某高校教务系统被学生用SQL注入改了成绩，操作方式简单到令人发指——在查分页面的URL参数后面加了个 UPDATE 语句。成绩单上的数字变了，数据库里的记录也变了，教务处过了两周才发现。金融系统里同样的操作可以把余额从100改成100万，医疗系统里可以把化验结果从阳性改成阴性。数据一旦失去可信度，整个业务逻辑就崩了。

还有一类危害经常被忽略：攻击者可以通过SQL注入让数据库服务器执行系统命令。SQL Server的 xp_cmdshell 存储过程、MySQL的 INTO OUTFILE 写文件功能，都能把数据库变成一个跳板。先拿数据库权限，再通过数据库拿服务器权限，最后在服务器上装后门、留木马。很多企业以为数据库在内网就安全了，但SQL注入往往就是从外网Web应用打进来的第一枪。

说个真实的细节。我见过一个电商网站的后台登录接口，用户名参数直接拼进SQL。用sqlmap跑了一下，三分钟出结果——数据库类型MySQL，当前用户root，权限FILE。这意味着攻击者不仅能读所有订单数据，还能往服务器上写文件。后来问开发为什么不参数化查询，回答是“项目赶工期，先上线再说”。这种心态太常见了，SQL注入能常年霸占OWASP Top 10，不是因为技术难防，是因为太多人觉得“不会轮到我”。

防御方法其实不复杂。参数化查询是根治手段，把数据和代码彻底分开，用户输入永远只是数据。存储过程、白名单校验、最小权限原则，都是有效的补充。但工具再好，写代码的人不执行就是零。我见过一个团队用了ORM框架，照样被注入——因为他们图方便，在ORM里直接拼SQL字符串。框架防不住人的偷懒。

SQL注入的危害链条很长：从绕过登录到拖库，从篡改数据到控制服务器。每一步的代价都在放大，而入口可能只是某个程序员少写了一个参数化查询。这事没有中间地带，要么防住了，要么等着出事。