PortSwigger SQL注入实验（四）
通过SQL注入查询MySQL 和 Microsoft数据库类型和版本

本实验来自 PortSwigger Web Security Academy，是 SQL 注入系列的第四个进阶实验。目标为：利用 UNION 攻击获取数据库类型与版本信息，并在页面中回显版本字符串。

通过该实验可以理解：UNION 注入攻击的基本流程——包括判断注入点、探测原始查询的列数、使用 NULL 占位符对齐列数，以及如何针对 MySQL 和 Microsoft 数据库使用版本变量（如 @@version）构造查询语句以获取系统信息。

【实验目标】
该实验的产品类别过滤器中存在 SQL 注入漏洞。
利用该漏洞，使用 UNION 攻击获取数据库版本字符串。

我们可以发现这个实验跟上个实验基本是一模一样的，只是把数据库类型由原来的Oracle变成了MySQL 和 Microsoft，那就简简单单让我水一篇博客吧（

1. 启动实验环境与 Burp Suite

启动实验环境后，可以看到与前几个 LAB 相似的购物页面。本次实验的注入点位于页面中的产品类别过滤器。

接下来启动 Burp Suite，进入 Proxy 模块下的 HTTP history 子页面。当浏览器中的代理配置生效后，此处将开始记录所有 HTTP 流量。

确认注入点位于过滤器后，就可以直接开始抓取并分析请求。

2. 开启代理并抓取过滤请求

启用浏览器中已配置好的 Burp Suite 代理，准备捕获过滤器请求。

先随意点击一个分类选项，观察 Burp Suite 中捕获到的数据：

根据路径特征（/filter?category=...），可以快速锁定产品类别过滤器对应的请求记录。

接下来我们右键将它发送至 Repeater 模块，以便后续进行重放与修改测试。

3. 分析请求数据并推测后端 SQL 逻辑

该请求是 GET 参数注入场景，核心请求行为可概括为：GET /filter?category=Pets HTTP/2。据此可推测后端可能执行类似查询：

SELECT * FROM products WHERE category = 'Pets'

4. 构造注入攻击

4.1 定位注入点

要破坏上述查询语句的原有逻辑，可先像之前一样利用单引号 ' 测试字符串边界。尝试在 Pets 后追加一个单引号，则查询可能变为：

SELECT * FROM products WHERE category = 'Pets''

这会触发 SQL 语法错误。我们在 Repeater 中将 category 的值改为 Pets' 并发送请求：

服务器返回 500 Internal Server Error，说明单引号被带入 SQL 语句并破坏语法，注入点得到确认。

【注意：注释符兼容性】
本题环境是 MySQL / Microsoft，注释符处理和 Oracle 题型略有区别。
若使用 --，请务必在后面加空格（如 -- ）；否则在部分数据库中可能语法错误。
本文示例使用 # 作为单行注释，写法更直观。

4.2 使用 ORDER BY 探测列数

为了使用UNION，接下来我们使用 ORDER BY n 来逐步探测列数：

• 先尝试 ' ORDER BY 1#
• 再尝试 ' ORDER BY 2#
• 继续尝试 ' ORDER BY 3# ...

当某个 n 导致报错时，说明该位置超出列范围，列数即为 n-1。

在本实验中，当 ORDER BY 3 报错，说明原查询共有 2 列。因此 UNION 语句也必须返回 2 列。

4.3 对齐列数并读取版本信息

既然目标查询需要 2 列，那么可以用 NULL 作为占位，构造如下 UNION 语句：

SELECT * FROM products WHERE category = '' UNION SELECT NULL, @@version  # 

4.4 构造最终 Payload

各组成部分的作用如下：

• '：闭合原 SQL 字符串。
• UNION SELECT：拼接注入查询结果。
• NULL, @@version：对齐 2 列，读取 MySQL 版本信息并让版本信息出现在可回显列中。
• # ：注释掉原查询后续内容。

最终可使用的请求示例：

GET /filter?category=' UNION SELECT NULL,@@version # HTTP/2

4.5 执行攻击请求

在 Repeater 中将 category 参数修改为 ' UNION SELECT NULL,@@version # ，点击 Send 发送：

返回 200 OK 且可以看到框中显示Solved，实验目标达成。

5. 总结与防御建议

本实验是一次典型的 基于 UNION 联合查询的 SQL 注入攻击。其根本成因包括：

• 产品类别过滤器参数被直接拼接到 SQL 语句中，未做安全处理；
• 应用将数据库错误直接回显给客户端，为列数探测提供反馈；
• 未采用参数化查询（Prepared Statement）或 ORM 安全接口。

防御措施：

• 参数化查询 —— 将 SQL 代码与用户数据彻底分离；
• 关闭详细错误回显 —— 生产环境屏蔽数据库报错细节；
• 输入校验与过滤 —— 对参数进行严格格式校验并转义危险字符；
• 最小权限原则 —— 数据库账户仅授予必要权限；
• 部署 WAF —— 拦截常见 SQL 注入特征作为纵深防御补充。

本实验展示了 UNION 注入在信息获取场景下的完整链路：先确认注入点，再探测列数，最后通过 NULL 占位实现回显。后续实验中，我将继续学习多列数据提取、跨表查询以及盲注等更复杂技术。

博客园技术分享 · 请勿用于非法测试