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