2017年，数据Equifax泄露了1.47亿人的库漏信用数据。事后调查发现，数据攻击者利用的库漏漏洞CVE-2017-5638早在三个月前就发布了补丁。三个月。数据够一个孕妇从查出怀孕到显怀了。库漏但Equifax的数据运维团队没打。

数据库漏洞这件事，库漏跟很多人想的数据不太一样。大众印象里，库漏黑客攻破数据库靠的数据是某种高深技术，像电影里演的库漏那样敲几行代码就进去了。实际情况更无聊：大部分数据库被攻破，数据是库漏因为没打补丁、密码太弱、数据或者端口直接暴露在公网上。

那些年我们踩过的坑

MongoDB在2017年出了一件荒唐事。安全研究员Chris Vickery发现，全球有超过两万个MongoDB实例在公网上裸奔，不需要密码就能连。攻击者连上来之后，把数据删掉，留一张勒索信：往这个比特币地址打0.2个币，我就把数据还你。有些攻击者更省事，数据都不备份，直接删。你打钱也拿不回来。

问题出在哪？MongoDB早期版本的默认配置绑定在0.0.0.0，也就是所有网络接口。安装完就能从外网连。很多开发者装完直接用，压根没想过要加认证。这个设计决策在2015年之前还算能接受，毕竟那会儿云服务没这么普及。到了2017年，大量MongoDB实例直接暴露在公网，等于把家门钥匙插在门上还贴了张纸条写地址。

Redis也差不多。默认无密码，默认绑定所有接口。攻击者连上来之后写SSH公钥，直接拿到服务器权限。2018年有个叫"RedisWannaMine"的挖矿蠕虫，专门扫未授权的Redis实例，中招的服务器CPU跑满，正常业务全挂。

SQL注入：老而不死

SQL注入是数据库漏洞里的活化石。1998年就有论文讨论这个，到现在2024年了，OWASP Top 10里它还在。不是因为它多难防，而是因为写代码的人总有人偷懒。

我见过一个真实案例。某电商平台的搜索接口，参数直接拼进SQL语句。用户搜"手机壳"，后端执行的是SELECT * FROM products WHERE name LIKE '%手机壳%'。攻击者输入' OR 1=1 --，整个products表就出来了。再输入' UNION SELECT username, password FROM users --，用户表也出来了。密码是MD5存的，彩虹表一查，一半用户的密码就还原了。

这个漏洞的修复成本极低。用参数化查询，把用户输入当数据而不是代码，十分钟改完。但很多团队就是不改，因为"业务跑得好好的，动它干嘛"。直到被拖库。

一个容易被忽略的事实

数据库漏洞的破坏力，往往不在数据库本身。数据库里存的往往是用户数据、订单、支付信息。一旦泄露，影响的是真实的人。Equifax泄露之后，有人因为信用记录被篡改，房贷被拒。有人身份被盗用，莫名其妙背了债。这些后果不会出现在CVE编号的描述里。

另一个事实：数据库漏洞的修复窗口期越来越短。以前一个漏洞从公开到被利用，平均有几周时间。现在自动化扫描工具遍地都是，漏洞公开后几个小时就有人扫全网。Shodan上搜一下"product:MongoDB"加上国家代码，能列出一堆未授权实例。攻击者不需要多高的技术，会用工具就行。

防御这件事，没有银弹

打补丁、设密码、限制访问来源、用参数化查询、最小权限原则。这些措施听起来老生常谈，但每一条都能挡住一大类攻击。问题在于，这些事做起来不酷，不出活，老板看不到。等到出事的时候，损失已经产生了。

数据库安全不是买一个防火墙就能解决的。它需要开发、运维、安全团队持续投入。但现实是，很多公司连一个专职的安全工程师都没有。代码能跑就行，数据库能连就行。这种心态下，漏洞永远补不完。