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/24.5 执行攻击请求
在 Repeater 中将 category 参数修改为 ' UNION SELECT NULL,@@version # ，点击 Send 发送：
返回 200 OK 且可以看到框中显示Solved，实验目标达成。
【本题最终 Payload】
' UNION SELECT NULL,@@version #
5. 总结与防御建议
本实验是一次典型的 基于 UNION 联合查询的 SQL 注入攻击。其根本成因包括：
- 产品类别过滤器参数被直接拼接到 SQL 语句中，未做安全处理；
- 应用将数据库错误直接回显给客户端，为列数探测提供反馈；
- 未采用参数化查询（Prepared Statement）或 ORM 安全接口。
防御措施：
- 参数化查询 ------ 将 SQL 代码与用户数据彻底分离；
- 关闭详细错误回显 ------ 生产环境屏蔽数据库报错细节；
- 输入校验与过滤 ------ 对参数进行严格格式校验并转义危险字符；
- 最小权限原则 ------ 数据库账户仅授予必要权限；
- 部署 WAF ------ 拦截常见 SQL 注入特征作为纵深防御补充。
本实验展示了 UNION 注入在信息获取场景下的完整链路：先确认注入点，再探测列数，最后通过 NULL 占位实现回显。后续实验中，我将继续学习多列数据提取、跨表查询以及盲注等更复杂技术。
博客园技术分享 · 请勿用于非法测试