官网：http://securitytech.cc/
Foundations & Hunting SSRF Checklist — SSRF 猎测手册（第 1 部分）
快速发现 SSRF。安全地证明它。拿到悬赏。第 1 部分教你如何识别 SSRF 信号、进行安全侦察，并在不外泄机密的前提下提供铁证。
要点摘要（TL;DR — 快速清单）
- 来自 UI 端点的出站请求
-
- 出乎意料的内部 IP DNS 解析
-
- 代理/出口日志命中 metadata 端点
-
- 文档渲染器可访问网络
-
- 通配的 IAM 策略
本文覆盖：什么是 SSRF、五个快速识别信号、安全测试方法、一个 30–60 分钟的快速猎测流程，以及可写入报告的防御建议。
为什么 SSRF 仍然高价值（你为什么要关心）
服务端请求伪造（Server-Side Request Forgery, SSRF）看起来很简单：攻击者诱使你的服务器代其发起网络请求。当服务器能访问仅限内部的端点（例如云 metadata、内网管理面板或防火墙后面的服务）时，这种能力就会变成高风险向量。
对于漏洞赏金猎人，SSRF 很香：相对常见、产品团队常常没测全、并且经常能拿到高危评级。但作为负责任的猎人，你必须安全地证明 SSRF——不外泄、不破坏，只给出可重复、可验证的证据。
（SSRF 流程示意 — 攻击者 → 易受攻击的服务器 → 内部资源 / metadata）
SSRF 解剖 — 去哪里找
SSRF 通常包含三步：
- 输入接收 — 应用接受来自攻击者的 URL 或主机（例如
?url=、webhook 目标、头像抓取器）。 -
- 解析并请求 — 应用解析 DNS 并对解析出的 IP/端口/协议发起连接。
-
- 使用抓取的数据 — 应用使用响应（渲染、解析、转换或信任响应头）。
任一步出问题都可被滥用。猎人的目标：找到能触发网络调用的输入，并采集非破坏性的证据证明服务器确实发起了这些调用。
5 个快速信号 —— 表明应用可能易受 SSRF（以及如何安全检测）
下面是原帖里总结的 5 个快速信号，我扩展了在真实环境中它们长什么样及如何安全测试。
1. 来自 UI 端点的出站抓取（Outbound fetches from UI endpoints）
观察点： /preview?url=、/fetch?src=、/avatar?image=、/convert?file=、/proxy?url= 等，或任何接受 URL 的 UI 输入。
为什么重要： 这些端点面向用户，常常在没有出口限制或主机验证的情况下直接发起请求。
安全检测方式：
- 盘点所有接受 URL/主机字符串的端点（含 GraphQL、JSON body、header）。
-
- 使用回调/协作者服务（Burp Collaborator、interactsh）检测 DNS/HTTP 回调，而不是去抓取内部资源。
-
- 先提交仅触发 DNS 解析的无害 URL（例如
http://<唯一 id>.interactsh.io/ping）。
- 先提交仅触发 DNS 解析的无害 URL（例如
2. 日志中出现意外的内部 IP DNS 解析（Unexpected internal IP DNS lookups）
观察点： 日志或监控里解析到 RFC1918 / link-local / 云 provider metadata IP 的记录。 为什么重要： 如果公共主机名被强制解析到内部 IP（通过 DNS rebinding 或 DNS 配置错误），攻击者可以让服务器与仅内部可达的系统通信。 安全检测方式：
- 使用 DNS 回调检测解析行为——无需实际访问内部服务即可证明解析发生。
-
- 若怀疑 DNS rebinding，注意应用是否在连接前校验解析出的 IP（多数不校验）。
重要警告：不要对第三方基础设施主动实施 DNS rebinding，除非在范围允许内并获得授权。
（DNS rebinding 示意）
3. 代理 / 出口日志显示对 metadata 端点的请求（Proxy/egress logs hitting metadata endpoints）
观察点： 日志里命中 169.254.169.254、metadata.google.internal 或其它厂商特定的 metadata 端点。
为什么重要： Metadata API 常暴露临时凭证、实例身份文档等敏感信息。即便一次对这些端点的请求也属于高危指标。
安全检测方式：
- 检查代理/NAT 日志是否有 metadata IP 的命中，抓取日志行、时间戳和请求元数据作为证据。
-
- 若能触发一个无害的回调并在代理日志中按时间关联到该回调，你就能在不抓取凭证的情况下注明可复现证据。
（示例代理日志 —— 请对敏感字段做脱敏处理）
4. 文档渲染器有网络访问（Document renderer has network access）
观察点： 用于渲染或转换不可信文档的服务（PDF 转 HTML、HTML 转 PDF、图片处理、Open Graph 抓取器等），这些服务在处理过程中可能会抓取外部资源（图片、字体、CSS）。 为什么重要： 渲染器会在处理攻击者控制的内容时发起网络抓取，为 SSRF 提供了简单通道。 安全检测方式：
- 上传引用到攻击者可控 URL（一个像素的图片就够），并监控协作者服务的回调。
5. 通配的 IAM 策略（Wildcard IAM policies）
观察点： 服务账号或角色权限过宽（例如策略里出现 *，或 S3 桶权限过度开放）。
为什么重要： 如果 SSRF 能访问 metadata 或身份 API，而服务身份权限过宽，影响会显著放大。原本有限的 SSRF 能力可能被利用来横向扩展权限。
安全检测方式：
- 在报告中证明 SSRF 能触发，但不要去检索凭证。说明如果能访问 metadata，会有何潜在影响（基于当前 IAM 策略推断风险）。
-
- 避免使用或暴露你或偶然获得的凭证，除非明确在 scope 中被允许。
（示例 IAM 策略片段，显示通配权限）
安全测试方法（必须遵循的流程）
这是你每次猎测都要遵循的伦理底线。
- 确认范围与规则 — 确认目标与技术在计划范围内，若不确定就问或跳过。
-
- 被动侦察 — 枚举接受 URL 的端点：检查客户端 JS、表单、API、GraphQL schema、公开文档。
-
- 非破坏性探测 — 使用协作者服务检测 DNS/HTTP 回调，而不是直接访问内部服务。
-
- 避免检索凭证 — 不要去抓取 metadata 或内部文件，除非项目显式允许。用回调、日志与响应作证据。
-
- 收集取证证据 — 时间戳、请求/响应捕获、协作者日志、代理/防火墙日志行，这些是最有说服力的证据。
-
- 在升级前停止 — 如果发现能访问 metadata 或凭证，立刻停止并联系项目以获得进一步授权或由 triage 处理。
30–60 分钟猎测速查（实战可执行）
当你拿到一个新目标时按此流程跑一轮，快速发现 SSRF 而且低噪音：
- 列出输入 — 在公开代码或客户端 JS 中 grep
url、uri、src、host、webhook、avatar。 -
- 映射端点 — 用 Burp 打开每个端点，记录输入类型（query param、JSON、header）。
-
- 回调探针 — 对每个候选输入提交
http://<unique>.interactsh.io/test。
- 回调探针 — 对每个候选输入提交
-
- 检查协作者日志 — 任何 DNS/HTTP 命中就是出站行为的证据。
-
- 日志关联 — 如果你能获得任何请求 ID（X-Request-ID）或服务器日志时间戳，把它们一并上交。
-
- 停止进一步探测 — 一旦发现指向内部的行为，别继续深入抓凭证，按范围上报与升级流程处理。
防护建议（每份报告里都可以附上的修复项）
工程师最爱清晰的缓解措施，给报告附上这些建议能提升采纳率：
- 网络出口白名单 — 默认拒绝出站，只允许必要目标。
-
- 网络层面屏蔽 metadata — 在防火墙/网关层阻断
169.254.169.254与提供商 metadata 名称。
- 网络层面屏蔽 metadata — 在防火墙/网关层阻断
-
- 协议白名单 — 限制
file:、gopher:、ftp:、ldap:等不必要协议。
- 协议白名单 — 限制
-
- DNS 解析后校验 IP — 解析主机后验证 IP 是否在禁止范围内再建立连接。
-
- 最小权限 IAM — 缩小服务账号权限，避免通配符策略。
-
- 隔离渲染器 — 将文档处理器放到无网络或受限网络的沙箱容器中运行。
（SSRF 修复示意）
结语（第 1 部分）
第 1 部分给你建立了心智模型和一套能可靠、合规地发现 SSRF 的速查清单。你现在知道去哪里找、如何在不破坏目标的前提下证明问题、以及该在报告里给出哪些防御建议。
第 2 部分将给出实操工具箱：PoC、Docker 实验环境、使用 interactsh 的可运行 PoC、以及准备好的可直接发送的报告负载模板，帮助你拿更大的赏金。
