sql注入漏洞的危害有哪些

2015年，英国电信运营商TalkTalk被一个17岁少年用最原始的危害SQL注入手法拖走了15.7万客户的银行账号和社保号。攻击者没用什么高级工具，入漏就是危害在URL参数里塞了一段' OR '1'='1。这事最后让TalkTalk赔了40万英镑，入漏股价一天蒸发近10%。危害一个单引号，入漏代价是危害上亿。

SQL注入的入漏本质是代码和数据没分家。程序员写SELECT * FROM users WHERE name = '$name'，危害用户输入' OR 1=1 --，入漏数据库就把后半截当命令执行了。危害问题出在字符串拼接这种偷懒写法上，入漏而它的危害破坏力取决于数据库连接用的是什么权限。

数据泄露只是入漏第一层

很多人以为SQL注入就是被拖库。对，但不全对。拖库是最常见的结果，但真正要命的是攻击者能拿到什么库。如果Web应用连数据库用的是sa或root，那整台服务器上的所有库都敞开了。2011年索尼Pictures被LulzSec用SQL注入攻破，泄露了上百万用户的密码、地址、生日。更糟的是，他们连内部系统的哈希密码也一并拿走。

我见过一个电商站，注入点在一个不起眼的优惠券查询接口。攻击者没直接拖用户表，而是先查information_schema，发现同库里有张admin_log表，记着后台所有操作日志。他顺着日志里的IP和时间，推断出管理员习惯在凌晨三点操作，然后挑那个时间窗口用注入写了个后门。整个过程数据库没报错，WAF也没拦住——因为流量看起来就像正常查询。

数据篡改比泄露更隐蔽

泄露是被人拿走，篡改是你自己都不知道数据已经错了。SQL注入可以执行UPDATE、INSERT、DELETE。一个在线教育平台被注入后，攻击者没偷东西，而是把所有已购课程的有效期改成了2099年。平台三个月后对账才发现，损失的是未来几十年的收入。还有更阴的：把竞争对手的商品价格批量改成0.01元，或者把论坛里所有帖子的作者改成同一个ID。

这类操作往往不触发任何告警。数据库日志里只是一条正常的UPDATE语句，管理员看到了也以为是运营在改数据。等到用户投诉“我买的课怎么过期了”或者“这个商品怎么标价一块钱”，已经过去几周了。

提权与内网渗透的跳板

数据库不是孤岛。MySQL有LOAD_FILE()读服务器文件，有INTO OUTFILE写文件。MSSQL更狠，xp_cmdshell直接调系统命令。一个注入点，如果数据库权限够，就能变成服务器上的shell。2017年某政府网站被注入，攻击者用INTO OUTFILE往Web目录写了个JSP木马，然后从数据库服务器横向扫内网，最后摸到了办公区的文件共享服务器。

很多运维觉得数据库只对内网开放就安全了。但Web服务器和数据库服务器通常在同一内网段，注入点就是那座桥。你防火墙再厚，桥是从里面搭的。

拒绝服务与业务中断

还有一种危害被低估：让数据库直接趴下。注入SELECT BENCHMARK(10000000, MD5('a'))这种语句，CPU瞬间跑满。或者用; SHUTDOWN直接关库。一个游戏公司的登录接口被注入了死循环查询，数据库连接池三分钟内耗尽，全服玩家掉线。攻击者没偷任何数据，纯粹是报复。恢复花了四小时，期间所有充值、对战、聊天全停。

SQL注入不像DDoS那样流量汹涌，一个请求就能让数据库CPU飙到100%。而且它走的是正常端口，流量清洗设备根本看不出异常。

修复的代价远高于预防

我参与过一次事后排查。一个注入漏洞在代码里存在了两年，期间被三个不同的攻击者利用过。清理的时候要对比数据库和备份的差异，逐条恢复被改的数据，通知所有可能受影响的用户，还要应付监管问询。开发团队停了新功能两周，全在补这个洞。如果用参数化查询，这行代码从一开始就不会有问题。

SQL注入是老问题，但老问题不代表没人踩。去年OWASP Top 10里它还在第三位。不是技术难防，是太多人觉得“我这个小站没人盯”。攻击者不挑大小，只挑有没有洞。一个自动化扫描器几分钟就能扫完全网，你的站再小，只要返回了数据库报错信息，就会被标记。

危害列不完，但核心就一句：数据库里有什么，攻击者就能拿什么、改什么、删什么。而数据库里通常有你能想到的一切。

(责任编辑：知识)