SSRF 服务端请求伪造

要解决的问题

当应用允许用户控制服务端发起的 HTTP 请求时，攻击者可以利用这个能力探测内网、访问云元数据接口，甚至借由目标服务器的权限进一步横向移动。SSRF 的危害面很广，但实际测试时很多人只停留在「传一个 URL 看看返回什么」的层面，遗漏了盲 SSRF、过滤绕过和权限升级等关键环节。这个技能把 SSRF 的测试流程拆成一套可执行的检查清单，帮助测试者系统地覆盖各个风险点。

核心能力与工作方式

技能按以下顺序组织测试步骤：

• SSRF 发现：识别应用中哪些参数会触发服务端请求，例如 url、callback、image_url 等字段，并验证是否可被操控。
• 盲 SSRF 检测：对于不直接返回响应的场景，通过 oastify.com 或 interactsh 等带外通道捕获请求，确认服务端是否真的发起了外部连接。
• 云元数据访问：尝试访问 AWS IMDSv1/IMDSv2（169.254.169.254）、GCP metadata 和 Azure IMDS 接口，评估是否能窃取临时凭证。
• 过滤绕过技巧：当应用对 URL 做了基本校验时，利用 IP 编码（十进制/十六进制）、0x7f000001 等技巧绕过正则；通过 DNS rebinding 绕过基于 IP 的黑名单；利用开放重定向构建重定向链以绕过域名白名单。
• SSRF 到 RCE 升级：在获得内网访问能力的基础上，尝试攻击未受保护的管理接口、利用目标上运行的 Redis/Docker API 等实现远程代码执行。

每一步都会记录哪些检查项已完成，并基于当前发现建议下一步方向。

适用边界与注意事项

• 本技能面向授权测试场景，如 bug bounty 或内部安全评估，不适用于未授权目标。
• 云元数据访问仅在目标实际部署于对应云平台时有效，本地或自建机房环境中这些端点不存在。
• DNS rebinding 等技巧需要可控的域名，部分环境下可能需要自建基础设施。
• 测试过程中注意区分 SSRF 与 SSRF 过滤器的行为差异，避免将「被拦截」误判为「不存在漏洞」。