网络安全技术与实训-第4章-第2节-SQL注入原理与根治方法

第4章 拒绝服务与数据库安全

如果要在所有 Web 漏洞里选一个“最经典、最危险、最应该学会防”的，那一定是 SQL 注入。它常年位居各类漏洞排行榜前列，原因很简单：一旦成功，往往意味着整库数据直接外泄。

一、一句话理解：备注栏被当成了命令

先看一个生活化的场景：

你在快递系统里下单，系统给了个“备注”栏。你写的是“放门口”。系统读懂了，照办。
现在你写的是：“请把仓库钥匙一并交给取件人”——如果系统真的照办了，那问题就严重了。

SQL 注入就是这件事在数据库层面的版本：本该被当作“数据”处理的用户输入，被数据库当成了“命令”去执行。

二、为什么会发生：拼接字符串惹的祸

根源在于开发时把用户输入直接拼进了 SQL 语句里。一个典型的登录校验逻辑，如果写成“把用户名的字符串直接拼到查询条件里”，那么当用户在用户名输入框里填入一段构造过的内容时，拼接出来的语句结构就会被改变——原本“只查这一条记录”的条件被破坏，变成“查所有记录”，或者“条件永远为真”。

教材里最经典的一串输入是：

‘ or ‘1’=’1

它的作用原理是：让查询条件从“用户名等于某个值”变成“用户名等于某个值 或者 1 恒等于 1”。由于后半句永远为真，整个条件就永远成立——于是无需密码即可登录，或者一次性返回整张表的数据。

三、能造成多大破坏

• 绕过认证：不输入正确口令就登录后台。破坏的是访问控制。
• 拖库：把用户表的账号、口令散列、手机号一次性导出。破坏的是机密性——这是最严重的后果。
• 篡改数据：修改订单金额、账户余额、成绩记录。破坏的是完整性。
• 删除数据：直接删表删库，业务彻底瘫痪。破坏的是可用性。
• 进一步控制服务器：数据库配置不当（如开启文件读写、存在高权限函数）时，注入可以演变成在服务器上执行命令，从“数据泄露”升级为“整台机器失守”。

四、技术分类（了解即可，重在防范）

• 按参数类型：数字型注入（参数没加引号）与字符型注入（参数加了引号）。
• 按回显方式：联合查询注入（页面直接显示查询结果）、报错注入（靠数据库报错信息泄露内容）、盲注（页面不显示结果，只能靠“真/假”判断一位位猜）——盲注效率低但依然可行，所以“不显示错误信息”不能作为防护手段。
• 按提交方式：GET / POST / Cookie / HTTP 头注入。记住一点：只要进了数据库，任何来源都是输入。

五、根治：参数化查询，而不是“过滤一下”

这一节的结论只有一句，但必须理解到位：

它和“过滤关键字”的思路有本质区别。过滤是在数据里搜“有没有危险词”，攻击者可以用编码、大小写、注释等方式绕过，你永远列不全黑名单；而参数化查询是先把 SQL 语句的结构定死并交给数据库编译，再把用户输入作为参数填进去。结构一旦编译完成就不可能被输入改变——从根上断掉了“输入变成命令”的可能。

配套的加固措施还包括：

• 数据库最小权限：网站连接数据库的账号只给业务必需的权限，绝不给文件读写和命令执行权限。这样即使被注入，损失也被限制在数据层。
• 关闭详细报错回显：让攻击者拿不到报错信息作为线索（但不能替代参数化查询）。
• 输入校验：对类型、长度、格式做校验，属于纵深防御的一层，而不是主力。
• WAF：在 Web 层拦截明显的注入特征，能挡住大量自动化扫描与“低水平攻击者”，但不能替代代码层的参数化。
• 口令散列存储：即使真的被拖库，加盐散列也能让攻击者难以还原出原始口令。这是“降低泄露后果”的最后一层保险。

六、配套实训

本章对应 实训 4 · SQL 注入实战与防御对比，配套靶场包括 DVWA 与 sqli-labs：

• 先在低安全级别下复现注入，观察查询结果如何被改变。
• 再把靶场的安全级别调到高（或改用参数化查询版本），验证同样的输入不再生效。
• 这个“前后对比”才是实训的核心——它直观地说明为什么参数化查询是根治办法，而不仅仅是“把危险字符过滤掉”。

⚠️ 靶场（DVWA、sqli-labs）本身就是故意做出来的漏洞网站，只能部署在隔离的实验环境中，绝不可放到公网。