躲过一劫！差点因为 SQL 注入被删库，这几点教训你必须知道

昨天服务器警报灯狂闪，差点以为职业生涯要结束了——原因无他，险些遭遇了传说中的 SQL 注入删库攻击。虽然最后是有惊无险，但这次经历确实让我出了一身冷汗，也让我重新审视了手里的安全配置。今天就借这个机会，跟大家聊聊这事儿是怎么发生的，以及我们到底该怎么防。

SQL 注入攻击概念演示图：攻击者通过恶意输入绕过数据库防御。

攻击到底是怎么发生的？

说起来有点搞笑，漏洞其实藏在一个特别不起眼的地方。这是一个很久没人维护的旧项目接口，代码里的查询逻辑是直接拼接字符串的。攻击者也没用什么高深莫测的黑科技，就是在参数里塞了一串带单引号的恶意命令。

简单的原理就是：程序原本只想查个 ID，结果因为没过滤单引号，把攻击者的 SQL 代码也当成命令执行了。一旦执行成功，对方不仅能读出你库里所有敏感信息，要是遇上个暴躁点的 DROP TABLE，你的数据瞬间就能灰飞烟灭。

为什么我们没能第一时间发现？

最讽刺的是，监控系统和 WAF（Web 应用防火墙）都在跑，但报警机制并没有第一时间触发。原因在于攻击者非常狡猾，他们前期只是做了一些低频的探测，也就是所谓的“盲注”。这类请求看起来跟正常的访问流量区别不大，没有明显的恶意特征码，防火墙很容易放行。

直到他们开始尝试提权或者拖库，流量特征才变得明显。但这时候，往往已经为时已晚。这也暴露了我们在安全审计上的一个巨大盲区：过于依赖自动化工具，而缺乏对异常业务逻辑的监控。

遇到这种事，第一时间该做什么？

如果你发现自己的数据库有被注入的迹象，千万别慌，按这个步骤来，或许能救命：

1. 立即断网：不要犹豫，先切断应用服务器的对外网络连接，防止攻击者进一步扩大战果，比如上传 Webshell 或者勒索病毒。
2. 保留现场：在没有备份日志之前，不要急着去重启数据库或服务，先把当时的 Web 日志、数据库慢查询日志甚至系统网络连接状态都拷贝出来。
3. 排查后门：SQL 注入往往只是第一步，攻击者可能已经写入了恶意文件。重点检查图片目录、临时目录下是否有异常的脚本文件。
4. 修补漏洞：找到被注入的代码点，这是根本。如果不修补，恢复数据后再次上线，还是会立刻被秒。

安全对比图：展示预编译语句如何有效防止 SQL 注入攻击。

这几点防御经验，建议赶紧记下来

针对这次事故，我总结了几个必须要落实的防御手段，大家看看自己的环境有没有缺漏：

1. 永远不要信任用户输入：这是铁律。所有的查询都必须使用预编译语句。无论是 Java 的 PreparedStatement，还是 Python 的参数化查询，或者是 PHP 的 PDO，务必把 SQL 逻辑和数据分离开。
2. 最小权限原则：这是最后一道防线。连接数据库的账号，千万不要给它 root 权限！如果只是读数据的接口，就只给 SELECT 权限；如果是普通的增删改，绝对不要给 DROP、TRUNCATE 或是 GRANT 权限。即使被注入了，攻击者也删不了库。
3. WAF 规则要调优：通用的防火墙规则拦截不住所有攻击，特别是针对性的业务逻辑漏洞。要针对自己的业务特点，配置一些正则规则，拦截那些包含 UNION SELECT、OR 1=1、information_schema 等敏感关键词的请求。
4. 代码审计不可少：定期用工具扫描代码，比如 SonarQube 或者专门查 SQL 注入的工具，把显眼的字符串拼接漏洞消灭在上线前。

结语

网络安全这事儿，不出事觉得是杞人忧天，出了事就是灭顶之灾。这次的经历提醒我，安全意识不能只停留在嘴上，每一个参数的校验、每一个权限的分配，都可能是救命的稻草。如果你的项目里有类似的历史遗留代码，趁着还没出事，赶紧去改改吧！