Order By注入漏洞实战：如何发现排序功能中的SQL注入盲区

本文为隐雾SRC学员的实战项目复盘。所有敏感信息已脱敏，仅供安全研究与教学交流。

你是否有过这样的经历：面对一个全是动态参数的网站，用 sqlmap 跑一遍，结果显示“System is stable”；换 Xray 挂着代理再跑一遍，依然零产出。而别人测试不到半小时，就提交了3个高危 SQL 注入漏洞。今天，我们就来复盘这3个发生在“灯下黑”地带的真实漏洞。

1. 先做个自测：你平时会测“排序”功能吗？

当你在抓包中看到下面这种参数时，你的第一反应是什么？

• 新手反应：只关注 search 输入框，因为那里能输入特殊字符。
• 工具思维：尝试在 orderFields 后面加单引号 ' 看是否报错，没有报错就判定为安全。
• 高手思路：识别出这是 ORDER BY 注入的高发区，明白这里不能使用常规语法，而应利用逻辑表达式进行探测。

如果你从未在 orderFields、sort、dir 这类参数上深入测试过，那么你可能已经错过了至少 20% 的 SQL注入 漏洞。

2. 漏洞复盘：一个“除以0”引发的逻辑判断

本次发现的3个漏洞，全部位于列表查询接口的 orderFields 参数中。

漏洞现象：
目标是一个业务管理平台。点击列表表头的“排序”按钮时，前端会发送一个 POST 请求，告知后端按哪个字段进行排序。

为何自动化工具会漏报？
因为开发人员虽然可能没有使用预编译，但可能做了简单的字符过滤，或者后端配置为不直接回显具体的 SQL 报错信息。当你发送 orderFields=create_time' 时，后端仅返回“操作失败”或空数据，自动化工具将其判定为正常的业务容错，直接跳过。

正确的人工测试思路（逻辑判断法）：
我们不依赖报错回显，而是利用 逻辑运算 来推断后端执行情况。

第一步：构造“真”命题
首先，确认该参数值确实被带入数据库执行。
构造 Payload：

case 1.0 when 1/1 then id **** cb_id ***

服务器返回了正常数据：

翻译一下：如果“1除以1”成立（这必然成立），就按 id 排序。
结果：服务器返回 200 OK，数据正常。

第二步：构造“假”命题（逻辑炸弹）
接下来是关键的验证步骤。将 Payload 修改为：

case 1.0 when 1/0 then id **** cb_id ***

此时服务器返回了错误：

翻译一下：如果“1除以0”成立... 等等，除数不能为零！数据库执行到此处会触发“除零错误”。
结果：服务器虽然未直接返回SQL错误详情，但接口逻辑异常，返回了“操作失败”等信息。

结论：
1/1 正常，1/0 报错。这足以证明后端将我们的参数作为逻辑表达式带入了数据库执行——SQL注入漏洞实锤。

3. 深入利用：从逻辑执行到数据窃取

一旦确认了 1/1（真）与 1/0（假）能引发不同的响应，接下来就可以进行典型的 布尔盲注 (Boolean Blind)。

报告中的攻击者构造了如下 Payload 来猜解数据库用户名：

case 1.0 when 1/(ascii(substr(user,1,1))-67) then id **** cb_id ***

• 如果用户名第一位是 'C' (ASCII 值为 67)，那么 67-67=0，表达式变为 1/0 —— 触发错误。
• 如果不是 'C'，分母不为 0 —— 返回正常。

通过遍历 ASCII 值，即可逐位猜解出完整用户名等敏感信息。

4. 为何必须改掉“一把梭”的测试习惯？

这3个漏洞给我们的最大警示是：不要过度依赖或迷信自动化工具的“智能”。以 SQLMap 为例，其默认测试等级 (--level 1) 通常不会深入探测 ORDER BY 子句，因为此处的注入语法与 WHERE 子句截然不同（不能直接使用 AND 1=1）。

请将以下 SOP（标准作业程序） 牢记于心：

1. 看到列表页 -> 必测排序功能。
2. 抓到数据包 -> 立即锁定 sort, order, orderField, field 等排序参数。
3. 手动测试：
   • 尝试 desc / asc 确认参数是否生效（列表顺序是否改变）。
   • 尝试 (case when 1=1 then id else update_time end) 等结构看是否引发语法错误。
   • 最有效的“逻辑炸弹”：尝试 1/0 或 1/(表达式) 的结构，通过布尔逻辑判断注入是否存在。

5. 提升效率：善用专项测试字典

每次都在 Burp Suite 里手动敲复杂的 case when 语句既低效又易错，而且不同数据库（如 MySQL、Oracle、PostgreSQL）的语法存在差异。高效的 安全测试 应该善用工具。可以准备一份 《Order By 注入专用 Fuzz 字典》，其中涵盖了主流数据库在排序参数下的逻辑判断 Payload。在测试时，直接将其导入 Burp Suite 的 Intruder 模块进行批量测试，能极大提升漏洞发现的效率和覆盖率。

希望这个实战案例能帮助你打开思路，在未来的渗透测试或 安全测试 中，不要放过任何看似“正常”的交互点。真正的漏洞往往隐藏在最容易被忽略的细节里。如果你对这类实战技术复盘感兴趣，欢迎在 云栈社区 与我们交流探讨。