hunt-shadow-api

OWASP API9 — 库存管理不当（影子 / 僵尸 API）

随着 API 不断演进，旧版本和内部 / 预发布路由往往仍然可以访问，却没有像当前版本一样获得安全修复——因为没人追踪它们是否仍然存在。问题很少出在某个端点本身，而在于同一操作中，旧版本与当前版本实施的安全措施之间存在差异。

适用场景

在以下情况下触发：

• 可以看到带版本号的路径（/v1/、/v2/、/api/2023-01-01/），或使用了 Accept / X-API-Version 标头。
• 更新日志、发行说明或弃用通知提到了已移除 / 旧版 API 行为。
• 移动 APK/IPA（通过 apk-redteam-pipeline / ios-redteam-pipeline）硬编码了端点，这些端点看起来对应比当前 Web 应用调用的版本更旧的后端。
• 可以发现多个 OpenAPI/Swagger 规范，或某个规范中的 info.version 表明还存在其他版本。

对于没有版本历史的单版本 API，请勿使用此方法——没有内容可供比较；应直接使用 hunt-api-misconfig，对现有的单一攻击面进行直接利用。

---

阶段 1 — 枚举完整的版本范围

# Path-based versioning
for v in v1 v2 v3 v4 beta alpha internal legacy old 2022-01-01 2023-01-01 2024-01-01; do
  curl -s -o /dev/null -w "%{http_code} /api/$v/\n" "https://$TARGET/api/$v/"
done

# Header-based versioning
curl -s -H "X-API-Version: 1" https://$TARGET/api/users
curl -s -H "Accept: application/vnd.company.v1+json" https://$TARGET/api/users

# Subdomain-based versioning
for sub in api api-v1 api-v2 apiv1 apiv2 legacy-api old-api internal-api staging-api; do
  curl -s -o /dev/null -w "%{http_code} $sub\n" "https://$sub.$TARGET/"
done

旧版本路径返回 200 / 401 / 403（任何不是 404 / 连接被拒绝的响应），都表示该版本仍在运行，值得带入阶段 3，即使它要求身份验证。

---

阶段 2 — 获取所有可访问的规范，而不仅是链接指向的规范

for path in openapi.json swagger.json v1/swagger.json v2/swagger.json v3/api-docs \
            api-docs.json swagger/v1/swagger.json .well-known/openapi.json; do
  curl -s -o /dev/null -w "%{http_code} /$path\n" "https://$TARGET/$path"
done

# Wayback Machine — a DEPRECATED version's spec often stays indexed after the live link is removed
curl -s "http://web.archive.org/cdx/search/cdx?url=$TARGET/*swagger*&output=json&collapse=urlkey"
curl -s "http://web.archive.org/cdx/search/cdx?url=$TARGET/*openapi*&output=json&collapse=urlkey"

如果能解析出多个规范（一个当前版本规范和一个归档 / 旧版规范），请直接比较其中的端点清单：

jq -r '.paths | keys[]' v1-swagger.json | sort > /tmp/v1_paths.txt
jq -r '.paths | keys[]' v2-swagger.json | sort > /tmp/v2_paths.txt
comm -23 /tmp/v1_paths.txt /tmp/v2_paths.txt   # in v1 only — candidates for "still live but forgotten"

对于差异中的每条路径，请确认它通过 v1 基础 URL 仍然可以访问。仅在旧版规范中记录、但仍返回非 404 响应的路由，是僵尸端点候选项——将其带入阶段 3。

---

阶段 3 — 比较旧版与当前版本的行为差异

对于两个版本中都存在的每项操作，请比较与安全相关的行为，而不是响应结构。响应结构差异仅供参考；行为上的安全回归才是要报告的问题。

• 身份验证强度。 旧版本是否接受当前版本会拒绝的无令牌、过期令牌或权限较低的令牌？

  curl -s -H "Authorization: Bearer $EXPIRED_TOKEN" https://$TARGET/api/v1/users/me -w '\n%{http_code}\n'
  curl -s -H "Authorization: Bearer $EXPIRED_TOKEN" https://$TARGET/api/v2/users/me -w '\n%{http_code}\n'
  

• 速率限制。 向两个版本中的等效端点发送相同数量的突发请求；如果旧版本没有返回 429，说明后来添加了速率限制，却从未回移到旧版本。
• 输入验证。 向两个版本发送完全相同的注入 / 超大 / 格式错误的负载；如果旧版本接受而新版本拒绝，说明加固只应用于新版本——根据负载针对的注入类型，继续使用相应流程（hunt-sqli、hunt-idor 等）。
• 字段暴露。 旧版本的响应正文是否包含当前版本已删减的字段——内部 ID、其他用户的数据、内部备注、PII？

---

阶段 4 — 当前 UI 从未引用的弃用 / 内部路由

• 在 JS 包中搜索没有可见 UI 流程会触发的 API 调用（/internal/、/admin/、/debug/、/_internal/、/test/、/staging/）——专门复用 hunt-source-leak 中用于搜索 JS 包的模式。
• 检查 robots.txt / sitemap.xml 中是否存在禁止访问的 API 路径——这属于自行造成的信息泄露。
• 移动应用端点清单（通过 apk-redteam-pipeline / ios-redteam-pipeline）通常会引用比当前 Web 应用调用的版本更旧的后端。将每个从 APK/IPA 获取的端点都视为候选项，与在线 Web API 进行版本差异比较。

误报筛选

• 仅版本不同（响应结构不同、字段名称仅有表面差异）属于信息性问题。只有向较早版本回溯时，身份验证、速率限制或验证机制变弱，才算安全相关回归。
• 声称行为存在差异前，先确认旧端点并非只是当前实现的别名或代理。发送一个在新旧逻辑下确实会产生不同结果的负载，而不只是比较响应正文中的版本字符串。
• 如果某个路径返回 200，但只提供“此 API 版本已弃用，请使用 v2”这样的静态消息，这不算发现问题——需确认底层操作仍会执行。

---

严重性表

发现	严重性
旧版本完全绕过身份验证，而当前版本要求身份验证	严重
旧版本缺少当前版本具备的速率限制	中到高（结合 hunt-brute-force）
与当前版本相比，旧版本泄露额外字段（PII、内部 ID）	中到高
旧版本接受当前版本已验证或清理的负载	高（结合底层注入类型）
版本可访问，但行为与当前版本完全相同	信息性

---

相关技能与组合

• hunt-api-misconfig — 在拿到规范或端点后负责利用（批量赋值、JWT 攻击、OData、Swagger 链式攻击）。此技能会为它提供更精准的目标：“这里有一个僵尸端点，其验证机制比当前版本宽松。”
• hunt-subdomain — 负责主机/子域名层面的发现（将 api-v1.target.com 作为独立主机，寻找潜在接管机会）。此技能负责在进入给定主机的版本范围后，查明其中的情况。
• hunt-source-leak — 使用 JS 包搜索内部/未公开调用；此处复用该技能，专门用于版本差异比较，而非提取密钥。
• apk-redteam-pipeline / ios-redteam-pipeline — 移动端构建通常会将较旧的 API 版本硬编码；每个从移动端发现的端点都可能存在版本差异。
• hunt-brute-force — 在此发现的速率限制回归，只有结合实际可暴力破解的影响（登录、OTP、枚举）后，才算完整发现。