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

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

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

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

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 语句并破坏语法，注入点得到确认。

4.2 为什么不能直接写 UNION

题目已给出目标数据库为 Oracle，因此我们需要注入类似 SELECT banner FROM v$version 的查询。但不能直接写成：

' UNION SELECT banner FROM v$version -- 

原因是：UNION 两侧 SELECT 的列数必须一致。若列数不一致，数据库会报错。

4.3 什么是“列”

在数据库表中，列（column）就是字段。比如下面这个建表示例中，id、name、age 就是 3 列：

CREATE TABLE student (
  id INT,
  name VARCHAR(20),
  age INT
);

回到本实验，后端查询里使用了 SELECT *，表示取出该表的所有列。UNION 注入时，右侧 SELECT 必须返回相同列数，否则会报错。

4.4 使用 ORDER BY 探测列数

由于无法直接看到后端查询列数，我们可以用 ORDER BY n 逐步探测：

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

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

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

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

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

SELECT * FROM products WHERE category = '' UNION SELECT NULL, banner FROM v$version -- 

4.6 构造最终 Payload

各组成部分的作用如下：

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

最终可使用的请求示例：

GET /filter?category=' UNION SELECT NULL,banner FROM v$version-- HTTP/2

4.7 执行攻击请求

在 Repeater 中将 category 参数修改为 ' UNION SELECT NULL,banner FROM v$version-- ，点击 Send 发送：

返回 200 OK 说明语法层面可执行。随后切换到浏览器访问对应 URL：

可以看到页面成功回显数据库版本字符串，右上角也显示 LAB Solved，实验目标达成。

5. 总结与防御建议

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

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

防御措施：

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

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

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