hunt-subdomain

高价值目标

子域名接管价值极高，因为攻击者可以从可信的公司自有域名提供内容——同时绕过浏览器同源信任、钓鱼过滤器和用户的警惕性。

收益最高的场景：

• 大型 SaaS 品牌（Shopify、Snapchat、Mozilla、Yelp）的子域名，其中可信域名包含用户会话上下文
• 由 CDN 支持的子域名（Fastly、CloudFront），其中 CNAME 指向未被认领的源站
• 第三方服务集成：UserVoice、WordPress.com、GitHub Pages、GitLab Pages、Heroku、Zendesk
• 预览／暂存／开发子域名（new.、preview.、course.、delivery.、addons-preview.）——功能发布后被弃用
• 用作 OAuth 重定向 URI 或 SSO 端点的子域名——这类目标收益最高

最重要的资产类型：

• 指向已停用第三方服务的 CNAME 记录
• 指向已弃用区域的 NS 委派
• 指向未分配云 IP 的 A 记录（较少见）
• 未被认领项目命名空间的 GitLab／GitHub Pages

---

攻击面信号

DNS 信号：

• CNAME 指向 *.github.io、*.gitlab.io、*.fastly.net、*.herokudns.com、*.wordpress.com、*.uservoice.com、*.zendesk.com、*.s3.amazonaws.com、*.azurewebsites.net、*.netlify.app
• CNAME 目标返回 NXDOMAIN 或 SERVFAIL，但父记录仍然存在
• NS 记录委派到已不再注册该区域的注册商

HTTP 响应信号：

• "There isn't a GitHub Pages site here"
• "NoSuchBucket"（S3）
• "The specified bucket does not exist"
• "No such app"（Heroku）
• "Sorry, this shop is currently unavailable"（Shopify）
• "This UserVoice subdomain is available"
• "Do you want to register"（任何域名停放页面）
• HTTP 404，且使用服务提供商特有的错误模板
• Fastly："Fastly error: unknown domain"
• "404 Web Site not found"（Azure App Service）

技术栈信号：

• 响应标头：X-Served-By: cache-*（Fastly）、X-GitHub-Request-Id、Server: Netlify
• CNAME 链解析到服务提供商的基础设施，但返回服务提供商的 404
• SSL 证书签发给服务提供商的通配符域名（*.fastly.net），而非公司域名

---

逐步狩猎方法

1. 枚举目标的所有子域名，结合被动和主动来源：

   • subfinder -d target.com -all
   • amass enum -passive -d target.com
   • assetfinder --subs-only target.com
   • 证书透明度：crt.sh/?q=%.target.com

2. 解析所有子域名，并标记以下情况：

   • 返回 NXDOMAIN
   • CNAME 指向第三方提供商

   cat subdomains.txt | dnsx -a -cname -o resolved.txt
   

3. 使用 nuclei 或 subjack 将 CNAME 与已知易受攻击的提供商指纹进行交叉比对：

   subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json
   nuclei -l subdomains.txt -t takeovers/
   

4. 对每个已标记的子域名进行手动验证：

   • dig CNAME subdomain.target.com — 确认 CNAME 存在
   • dig A <cname-target> — 确认返回 NXDOMAIN 或无法解析
   • curl -sk https://subdomain.target.com — 检查提供商的错误字符串

5. 确认是否可认领 — 尝试注册该资源：

   • GitHub Pages：检查 <username>.github.io/<repo> 或组织页面是否尚未被认领
   • GitLab Pages：检查项目命名空间
   • S3：尝试运行 aws s3api create-bucket --bucket <bucketname>
   • UserVoice/Zendesk/WordPress：访问注册 URL
   • Fastly：检查源站主机名是否尚未注册

6. 认领该资源（只需足以证明控制权，切勿提供恶意内容）：

   • 创建一个包含你的 HackerOne 用户名和时间戳的最简索引页
   • 截图，展示你的内容已通过 subdomain.target.com 提供

7. 记录整个链路：CNAME 记录 → 提供商目标 → 未认领的资源 → 你的内容

8. 评估影响升级情况：

   • 该子域名是否出现在 OAuth 重定向允许列表中？
   • 它是否与父域名共享 Cookie（domain=.target.com）？
   • 它是否在应用的 CSP 中被引用？
   • 它能否接收经过身份验证的 API 调用？

9. 在释放认领之前撰写报告（某些计划希望先进行验证）

---

载荷与检测模式

批量提取 CNAME 并检测 NXDOMAIN：

# Extract CNAMEs and check if target resolves
while read sub; do
  cname=$(dig +short CNAME "$sub" | head -1)
  if [ -n "$cname" ]; then
    result=$(dig +short A "$cname")
    if [ -z "$result" ]; then
      echo "[POTENTIAL] $sub -> $cname (NXDOMAIN)"
    fi
  fi
done < subdomains.txt

Nuclei 接管扫描：

nuclei -l subdomains.txt -t ~/nuclei-templates/http/takeovers/ -severity medium,high,critical

启用 SSL 的 subjack：

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c $GOPATH/src/github.com/haccer/subjack/fingerprints.json -v

提供商指纹 grep 模式：

curl -sk "https://$subdomain" | grep -iE \
  "there isn't a github pages|no such bucket|no such app|this uservoice|fastly error: unknown domain|do you want to register|sorry, this shop|project not found|404 not found|unclaimed"

检查子域名是否属于 Cookie 的作用范围（共享父域名）：

curl -Isk "https://target.com" | grep -i "set-cookie" | grep "domain=.target.com"

Fastly 专用检测：

curl -sI "https://subdomain.target.com" -H "Host: subdomain.target.com" | grep -i "fastly\|x-served-by\|x-cache"
curl -sk "https://subdomain.target.com" | grep -i "fastly error"

检查未认领的 S3 存储桶：

aws s3api head-bucket --bucket <extracted-bucket-name> 2>&1 | grep -i "NoSuchBucket\|403\|404"

GitLab Pages 专用检测：

dig CNAME sub.target.com
# If pointing to *.gitlab.io — visit the gitlab.io URL directly
# 404 from gitlab.io project = claimable

---

常见根本原因

1. 停用服务后未清理 DNS — 开发者删除了 Heroku 应用、UserVoice 账户或 WordPress 站点，却没有删除 CNAME 记录。DNS 永远保留，服务却已不复存在。

2. 发布后遗弃暂存/预览基础设施 — 为产品发布配置了 course.、new.、preview.、beta. 子域名并指向第三方，但在活动结束后便被遗忘。

3. 由第三方团队配置子域名 — 市场团队通过 IT 设置了 UserVoice 或 Zendesk 子域名，产品停止使用后，该子域名的 DNS 仍由不知情的工程团队管理。

4. CDN 配置错误且未验证源站 — Fastly 等 CDN 过去允许用户通过创建指向某个后端主机名的服务来“认领”该域名。未注册的源站主机名因此可被认领。

5. 未保留 GitHub/GitLab Pages 命名空间 — 组织重命名、用户账户被删除，或仓库被设为私有/删除，但 Pages CNAME 仍指向旧命名空间。

6. 通配符 DNS 条目 — *.target.com 指向云服务提供商，意味着任何未认领的子域名都可能解析到可认领的基础设施。

7. 收购/剥离后的公司 DNS 未清理 — 收购后，原品牌的子域名（例如 Shopify 旗下的 oberlo.com）仍保留指向已不再付费使用的服务的 CNAME。

---

绕过技巧

防御：发布前手动审查指纹

• 绕过：使用其他错误字符串——服务提供商会更改其 404 页面。维护最新的指纹列表。一些服务提供商在 HTTP 和 HTTPS 下会显示不同的错误。两种协议都要测试。

防御：范围限制（范围内仅包含主域名）

• 绕过：仔细检查程序的资产列表——*.target.com 通配符通常会隐式包含子域名。提升问题影响，以将其纳入范围。

防御：因时间因素收到“无法复现”的回复

• 绕过：提交问题后立即截图。录制视频演示。热门子域名的可利用窗口可能很短。

防御：HTTPS 证书不匹配，无法提供证明

• 绕过：一些服务提供商（GitHub Pages、Netlify）会为已认领的域名自动配置 TLS。其他服务提供商则不会——展示 HTTP 接管，并说明认领后服务提供商会解决 TLS 问题。

防御：服务提供商端验证（Fastly 验证域名所有权）

• 绕过：某些 Fastly 配置不会验证源主机名。检查 CNAME 目标是通用 Fastly 后端主机名，还是经过客户验证的主机名。仍可尝试认领并观察结果。

防御：对子域名枚举进行速率限制

• 绕过：仅使用被动数据源（SecurityTrails、Shodan、crt.sh、VirusTotal），以避免触发 WAF/IDS。DNS 解析不会访问 Web 服务器。

防御：程序声称“严重性低／没有影响”

• 绕过：通过证明同源 Cookie 窃取、OAuth 重定向滥用或 CSP 绕过来提升影响。检查 JS 中是否有任何 postMessage 的 targetOrigin 检查列出了该子域名。

---

Gate 0 验证

1. 攻击者现在能做什么？ 你能否注册未被认领的资源（GitHub 仓库、S3 存储桶、Heroku 应用、UserVoice 账户），并在目标的受信任域名下提供任意内容——包括钓鱼页面、凭据窃取程序或恶意脚本？

2. 受害者会失去什么？ 用户会失去信任和安全感：他们看到的是一个由攻击者提供内容、却带有公司品牌的 URL。公司会失去品牌完整性；如果该子域名属于 domain=.target.com 的作用范围，还可能泄露会话 Cookie，并可能导致 OAuth/SSO 流程遭到劫持。根据 CSP 配置，可能还会对主应用造成 XSS。

3. 能否从头开始在 10 分钟内复现？

   • dig CNAME subdomain.target.com → 确认 CNAME 指向服务提供商
   • curl -sk https://subdomain.target.com → 确认服务提供商的错误字符串
   • 访问服务提供商的注册页面 → 确认该命名空间可用
   • 对以上三个步骤截图 = 可在 10 分钟内复现

如果无法证明服务提供商的资源当前未被认领且可以认领，这就不是有效的报告。

---

真实影响示例

场景 A — 通过已弃用的 SaaS 发起可信品牌钓鱼攻击（Snapchat/UserVoice） 攻击者发现 feedback.snapchat.com 的 CNAME 指向一个 UserVoice 子域名。UserVoice 账户已被取消，但 DNS 记录仍然存在。攻击者免费注册了匹配的 UserVoice 子域名，从而控制了 feedback.snapchat.com。任何访问该 URL 的用户——可能是通过旧书签或 Google 搜索结果访问——都会在带有 Snapchat 品牌的域名上看到攻击者控制的内容。由于浏览器信任该域名，从此子域名发起的钓鱼活动可以绕过检查域名信誉的电子邮件安全过滤器。

场景 B — CDN 源站接管导致同源攻击（Mozilla/Fastly） addons-preview-cdn.mozilla.net 的 CNAME 曾指向一个不再注册在 Mozilla 的 Fastly 账户下的 Fastly 源站主机名。攻击者可以创建一个声明使用该源站主机名的 Fastly 服务，使发往 addons-preview-cdn.mozilla.net 的所有请求都路由到攻击者控制的 Fastly 基础设施。由于该子域名与主域名 mozilla.net 相同，它可被利用来提供看似来自 Mozilla 基础设施的恶意 CDN 资源，从而可能绕过允许 *.mozilla.net 的 CSP 规则。

场景 C — 产品迁移后被弃用的预发布子域名（Rails/GitHub Pages） new.rubyonrails.org 曾指向一个用于网站改版项目的 GitHub Pages 部署。新网站上线后，旧 GitHub 仓库被删除或设为私有，但 DNS CNAME 仍然存在。攻击者可以分叉或创建匹配的 GitHub Pages 仓库，并抢占该命名空间，从而在 new.rubyonrails.org 下提供内容。由于这是 Ruby on Rails 的官方域名，在此提供的任何内容——包括虚假的下载链接或恶意 gem——都会带有 Rails 品牌的全部信誉。

---

已披露报告引用（2022-2023）

以下协同披露 / 漏洞分析案例通过现代服务提供商指纹（Vercel/Azure cloudapp/Zendesk 时代）和明确的 ATO 链示例扩展了本技能。引用 #12 和 #13 是外部漏洞分析（并非已披露的 HackerOne 报告）——其奖金金额未经验证；只有 #14 有公开的 H1 报告 ID。

12. Microsoft Azure DevOps — 两个 cloudapp.azure.com 子域名 + 通配符 *.visualstudio.com OAuth reply_to → 一键 ATO（Binary Security 漏洞分析）

    • 子类：Azure cloudapp.azure.com 区域池中的悬空 CNAME——链至 ATO
    • ATO 链：是 — app.vssps.visualstudio.com/_signin?reply_to=https://feedsprodwcus0dr.feeds.visualstudio.com/ 将所有 *.visualstudio.com 列入白名单。攻击者认领了悬空的 Azure VM 主机名，随后构造登录 URL，将 JWT 和 FedAuth 令牌返回到攻击者控制的端点
    • 认领流程：发现悬空的 cloudapp.azure.com CNAME，在同一 Azure 区域部署免费层 VM，并申请完全相同的已释放主机名；Azure 按先到先得原则重新分配名称
    • 年份：2021 年 2 月报告，2022 年 11 月披露 — MSRC 明确将其列为范围外（因利用了子域名接管），$0

13. 匿名 H1 — admin-support.xyz.com → 未认领的 Zendesk → 拦截电子邮件 → ATO（0xprial 撰写的漏洞分析）

    • 子类：通过 xyzdocs.zendesk.com 主机映射接管 Zendesk 帮助台
    • ATO 链：是 — 研究人员在被劫持的 Zendesk 实例上配置邮件转发，拦截包含支付信息和密码重置邮件的 [email protected] 工单，随后触发客户账户的密码重置，使重置链接送达攻击者的 Zendesk 收件箱
    • 认领流程：dig CNAME 返回 xyzdocs.zendesk.com（未注册）→ 注册免费的 Zendesk 试用版 → 添加 xyzdocs 作为子域名 → 为 admin-support.xyz.com 启用主机映射
    • 年份：2023 — 奖金据 0xprial 漏洞分析所述（博客来源；没有公开的 HackerOne 报告 ID，请视为未经验证）

14. Vercel 已删除项目接管 — 指向已移除 Vercel 项目的悬空 cname.vercel-dns.com CNAME，可通过以该名称部署新项目重新认领。

    • 子类：项目删除后遗留的 Vercel 悬空 CNAME（cname.vercel-dns.com）
    • 影响：加密货币 DEX 网络钓鱼 — proxies. 子域名被信任用于 RPC 代理路由；攻击者可在“可信”子域名下提供恶意的盗取钱包 JS
    • 认领流程：子域名返回 Vercel 404 DEPLOYMENT_NOT_FOUND → 创建免费 Vercel 项目 → Settings → Domains → 添加 proxies.sifchain.finance — Vercel 会验证现有 CNAME，并在没有带外所有权证明的情况下自动签发 TLS
    • 年份：2022 — Sifchain 将其视为严重问题（web3 网络钓鱼途径）

Fastly CDN 悬空服务技术（通用，并非单个已披露报告）：

• 指纹：子域名返回 Fastly error: unknown domain. Please check that this domain has been added to a service
• 认领流程：注册 Fastly 免费试用版 → 创建新的 CDN 服务 → 将悬空主机名添加为服务域名
• 根本原因：Fastly 历来不会在创建服务时验证 CNAME 所有权；任何指向 Fastly 任播地址的 CNAME 都可关联到新服务
• 潜在 ATO 链：若父域名在 script-src 中信任 assets./CDN 主机，则可串联 CSP 绕过 + JS 注入

---

链与组合（资深猎手）

在大多数成熟的漏洞奖励计划中，单独的子域名接管影响等级为低到中等 / 仅供参考——篡改非关键业务子域名并不吸引人。链式利用的奖金是单独利用的 10-100 倍。**提交前，应针对以下五种链逐一评估每次接管。**若均不适用，则为低危；若适用一条，则为高危；若两条组合，则为严重。

链 1 — 接管 + OAuth redirect_uri 白名单 → 窃取授权码 → 一键账户接管（ATO）

• A. 通过 /oauth/authorize 流程枚举 OAuth redirect_uri 允许列表。查找任何通配符 *.target.com，或静态列表中任何可被接管的候选主机名（例如 feedsprod.feeds.visualstudio.com、legacy.target.com）。
• B. 在该允许列表中找到可被接管的子域名。通过提供商的入驻流程认领它（Vercel 项目、Azure cloudapp 区域池、S3 存储桶、Heroku 应用、Zendesk、Shopify 店面——参见上文披露报告引用）。
• C. 在认领的子域名上托管 OAuth 回调接收端。将受害者引导至 /oauth/authorize?redirect_uri=https://legacy.target.com/cb&response_type=code&client_id=<legit>。受害者的浏览器已有会话 → 授权透明完成 → 授权码落入攻击者主机。通过令牌端点交换 → 账户接管（ATO）。
• 影响： 可对目标的所有用户实施持久的一键账户接管。OAuth 流程对用户是隐式的（如果此前已同意，则不会出现同意页面），因此只需点击攻击者链接一次。
• 真实案例形态： Microsoft Azure DevOps cloudapp.azure.com + 通配符 *.visualstudio.com reply_to 链（Binary Security，2022 年 11 月——披露报告引用 #12）。多个 SaaS 项目在 H1 上披露了 OAuth 允许列表配置过于宽松的问题。

链 2 — 接管兄弟子域名 + Cookie 域通配符 → 父级应用上的会话固定

• A. 检查主应用（app.target.com）设置的 Cookie。如果 Set-Cookie 使用 Domain=.target.com（父域作用域）而不是仅限主机的 Cookie，Cookie 就会泄露到每个兄弟子域名——包括已被接管的子域名。
• B. 接管任意兄弟子域名（legacy.target.com、feedback.target.com、assets.target.com）。现在，被接管的主机可以为父域设置 Set-Cookie。
• C. 通过被接管主机上的脚本植入 Set-Cookie: SESSIONID=<attacker_session>; Domain=.target.com。受害者访问 app.target.com 时会附带攻击者的会话 Cookie。服务器将其视为攻击者账户 → 通过会话固定实现账户接管（ATO）。
• 影响： 无需 OAuth 或重置密码即可实现账户接管——完全依靠 Cookie 域泄露。当父级应用使用未添加 __Host- 前缀的会话 Cookie 时尤其有效。
• 真实案例形态： hunt-auth-bypass 中的 Duende BFF 攻击类别 2 对此进行了深入讨论（Cookie 域通配符会将子域名接管转变为会话固定）。模式类别：S3 存储桶接管与父域作用域（Domain=.target.com）Cookie 结合。

链 3 — 接管 + CSP script-src 包含被接管主机 → 主应用上的持久型存储 XSS

• A. 检查主应用 HTML 响应中的 CSP 标头。查找 script-src 'self' assets.target.com cdn.target.com legacy.target.com ...。
• B. 接管 CSP 允许列表中的一个子域名（常见目标尤其包括：指向已删除 CDN 的过期 CNAME、已删除的 Vercel/Netlify 项目、已归档的分析服务）。
• C. 在被接管的主机上托管攻击者控制的 JavaScript。主应用的每次页面加载都会获取 <script src="//taken-over-host/x.js">，因为该主机位于 CSP 允许列表中。JS 以主应用的来源执行——可完全访问会话，并能调用任何同源 API。
• 影响： 主应用的每个页面都相当于存在存储型 XSS，且会持续有效，直到更新 CSP。由于 CSP 将该 JS 源视为“可信”，因此可绕过所有输入清理器。
• 真实案例形态： Sifchain 的 proxies.sifchain.finance Vercel 接管——披露报告引用 #14（Web3 钓鱼）；多篇 2020-2024 年 H1 披露报告记录了此类模式。

链 4 — 接管 + CORS Access-Control-Allow-Origin 正则匹配 → 携带凭据的跨域 API 读取

• A. 检查 API 的 CORS 配置。查找 Access-Control-Allow-Origin 中是否存在包含 *.target.com 或 target.com.* 的正则 / 通配符 / 后缀匹配（第二种是常见错误）。
• B. 接管 CORS 正则会接受的任意子域（或者，如果后缀匹配存在漏洞，则注册新的 target.com.attacker.com 主机）。
• C. 托管在被接管子域上的攻击者页面发起 fetch('https://api.target.com/account', {credentials:'include'})。CORS 预检通过。服务器返回携带凭据的响应。攻击者的 JS 可以读取该响应。
• 影响： 大规模跨租户 API 读取，可获取会话、PAT、账户数据、账单记录——只需一个攻击者页面即可访问全部内容。
• 真实案例特征： 有多个已披露案例；交叉参考 hunt-api-misconfig 的 CORS 小节。可与 hunt-misc 步骤 1（CORS 正则枚举）配合。

链 5 — 接管电子邮件 DNS（DKIM / SPF / MX）→ 电子邮件伪造 → 冒充母品牌进行可信钓鱼

• A. 枚举目标的电子邮件 DNS——DKIM 选择器（selector1._domainkey.target.com）、SPF 包含项（include:_spf.takeover-candidate.com）、MX 记录（mx.target.com → defunct-provider.example）。
• B. 接管任意 DKIM 选择器或 SPF 包含项主机。此时攻击者可以发布 DKIM / SPF 记录，授权自己的服务器以 @target.com 名义发送邮件。
• C. 向受害者发送钓鱼邮件，邮件头为 From: [email protected]。收件人的邮件服务器通过 SPF + DKIM 检查（因为接管的服务器现在已获授权）。邮件以 target.com 品牌形象进入收件箱，且没有安全警告。
• 影响： 利用母品牌实施极具成效的钓鱼活动。由于所有身份验证检查都通过，受害者会信任该邮件。可用于窃取凭据、实施 BEC 欺诈、获取供应链访问权限。
• 真实案例特征： 历史上有多个关于 DKIM 选择器接管 / SPF 包含项链劫持的披露案例。交叉参考 offensive-osint 中的 DMARC / SPF / DKIM 小节。

操作人员层面的模式

实际上，上述五条攻击链几乎涵盖了所有高级别子域接管漏洞赏金案例。报告任何接管问题之前，都要逐项检查：

1. OAuth redirect_uri 允许列表——被接管的主机是否出现在其中？→ 链 1，严重。
2. 父域 Cookie——主应用是否设置了 Domain=.target.com？→ 链 2，高危。
3. CSP script-src——被接管的主机是否出现在允许列表中？→ 链 3，严重。
4. CORS 允许列表——是否有任何正则匹配被接管的主机？→ 链 4，高危。
5. 电子邮件 DNS（DKIM 选择器 / SPF 包含项）——被接管的主机是否出现在其中？→ 链 5，高危。

如果以上都不适用，则按低危 / 信息级提交。如果无法证明其中一条攻击链，请勿按严重级提交——否则分诊人员很快就会下调等级。

交叉参考：

• hunt-oauth — 链 1（redirect_uri 绕过类别）
• hunt-auth-bypass Duende BFF 攻击类别 2 — 链 2（Cookie 作用域）
• hunt-xss 链 4 — 链 3（通过受信任来源 JS 绕过 CSP）
• hunt-api-misconfig CORS 小节 — 链 4
• offensive-osint 电子邮件安全小节 — 链 5

---

相关技能与链路

• hunt-cloud-misconfig — 大多数过期的 CNAME 都指向已删除的云资产（S3、CloudFront、Heroku）。链路原语：云配置错误（S3 已删除）+ hunt-subdomain → 未被认领的 CNAME 指向存储桶 → 认领存储桶名称 → 完全控制子域名。
• hunt-oauth — OAuth redirect_uri 主机上的接管漏洞 = 整个 SSO 范围内持续存在的 ATO。链路原语：接管 auth.target.com 子域名 + OAuth redirect_uri 允许列表 → 窃取授权码 → 每当用户重新进行身份验证时即可接管其账户。
• hunt-api-misconfig — CORS 正则表达式通常会将可被接管的子域名加入允许列表。链路原语：子域名接管 + 带凭据的 CORS *.target.com → 通过凭据读取跨域 API → 大规模 IDOR。
• hunt-xss — 已认领的子域名与共享会话 Cookie 的同级子域名处于同源。链路原语：接管 feedback.target.com 子域名 + Cookie 作用域 .target.com → 托管在接管主机上的 JS 读取主应用 Cookie → 劫持会话。
• security-arsenal — 加载 27 种以上的子域名接管指纹表（NoSuchBucket、“no such app”、GitHub Pages 404 字符串、Heroku、Shopify、Fastly）以及 subzy/subjack 自动化模式。
• triage-validation — 应用唯一标记门槛：仅接管本身属于信息性发现；只有在被认领的主机上发布唯一 HTML 标记，并证明存在下游影响（Cookie 读取、OAuth 链路、CSP 绕过）后，才提交报告。