数据库的漏洞

2017年，数据Equifax公司的漏洞数据库被攻破，1.43亿美国人的数据社保号码、驾照信息、漏洞信用卡数据被拖走。数据事后调查发现，漏洞攻击者利用的数据是一个早在三个月前就公布补丁的Apache Struts漏洞。数据库本身没有错，漏洞错的数据是没人给它打补丁。这件事让我意识到，漏洞所谓数据库漏洞，数据十有八九不是漏洞技术问题，而是数据管理问题。

数据库漏洞分两种。漏洞一种是数据软件本身的缺陷，比如Oracle、MySQL、PostgreSQL时不时曝出的权限提升漏洞。另一种更隐蔽——配置错误。我见过太多企业把数据库端口暴露在公网上，用弱密码，甚至用默认账号。2019年，某安全公司扫描发现，全球有超过4万个MongoDB实例没有任何认证保护，裸奔在互联网上。这些数据库不是被攻破的，是被人直接走进去拿走的。

SQL注入是数据库漏洞里的老面孔了。原理简单到令人发指——把恶意代码塞进查询语句里。很多程序员以为参数化查询就能一劳永逸，但现实是，存储过程、动态拼接、ORM误用，都能让防护失效。我认识一个白帽黑客，他说自己测试过的网站里，至少有三分之一存在SQL注入点。这不是技术难题，是开发习惯问题。

还有个容易被忽略的漏洞——备份文件。很多公司把数据库备份放在同一台服务器上，或者备份权限设置不当。一旦主库被攻破，备份库就是下一个目标。2018年，新加坡SingHealth数据库遭入侵，150万人的健康记录被窃取。事后调查发现，攻击者先拿下了管理员的个人电脑，然后顺藤摸瓜找到了数据库备份的存储位置。数据库漏洞从来不是孤立的，它是一个链条上最薄弱的那一环。

我不太相信"数据库本身很安全"这种说法。任何系统都有缺陷，关键是你能不能及时发现并修复。有些公司的数据库漏洞扫描报告积压了半年都没人处理，为什么？因为修漏洞需要停机，需要测试，需要协调各方资源。业务部门不同意停机，运维部门怕担责任，安全部门只能干瞪眼。这已经不是技术问题了，是组织架构的漏洞。

说点实际的。如果你是数据库管理员，别只盯着CVE公告。先检查你的数据库有没有开启审计日志，有没有限制访问来源IP，有没有定期更换密码。这些基础工作比追逐最新漏洞重要得多。数据库漏洞就像家里的门锁——再好的锁也挡不住你不关门的习惯。