SSRF 与开放重定向漏洞防御实战

AWS:      http://169.254.169.254/latest/meta-data/
Azure:    http://169.254.169.254/metadata/instance?api-version=2021-01-01
GCP:      http://metadata.google.internal/computeMetadata/v1/
阿里云:    http://100.100.100.200/latest/meta-data/

# 1) 读取临时 IAM 凭证
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# 返回一个角色名，例如 web-app-role

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/web-app-role
# 返回 AccessKeyId / SecretAccessKey / Token（短期有效）

# 2) 用拿到的凭证，直接调用 AWS API 提权/拖数据
aws s3 ls s3://内部存储桶 --profile stolen

内网扫描：   http://10.0.0.1/ ~ http://10.0.0.254/
                用超时与响应差异，逐段摸清内网存活主机与端口
Redis 未授权： http://127.0.0.1:6379/ 配合 gopher:// 写 crontab/SSH key
内部管理台：   http://内网IP:8080/ 未授权访问的监控/管理面板
数据库/ES：    http://内网IP:9200/ ES、:3306 MySQL、:6379 Redis

绕过 IP 黑名单的常见写法：
  http://2130706433/               # 127.0.0.1 的十进制整数形式
  http://0x7f000001/               # 十六进制
  http://0177.0.0.1/               # 八进制
  http://127.1/                    # 省略写法
  http://0/                        # 0.0.0.0
  http://[::1]/                    # IPv6 回环
  http://127.0.0.1%23foo/          # URL 编码
  http://127.0.0.1.nip.io/         # DNS 解析到 127.0.0.1
  http://user:pass@127.0.0.1/      # 用户名密码混淆

重定向跟随（Redirect following）：
  攻击者传一个「自身合法」的 URL（如 https://safe.example.com）
  该地址 302 跳到 http://169.254.169.254/... → 服务端跟随 → 打到元数据
  防御方只校验了初始 URL，没限制后续跳转目标

协议走私（Protocol smuggling）：
  用 file://、gopher://、dict:// 等非常规协议
  读取本地文件（/etc/passwd）、或构造 Redis 协议报文

① 协议白名单：只允许 http:/https:，其余（file/gopher/dict/ftp）一律拒绝
② 域名白名单：只允许业务需要的域名/后缀，其余一律拒绝
③ 若必须开放任意 URL：把「抓取」放到专用隔离服务（如 headless 容器），
   且该服务无内网路由、无云凭证、无敏感权限

// 校验伪代码：解析 → 检查 IP → 按 IP 建连（而非按域名）
ips := net.LookupIP(host)
for _, ip := range ips {
    if isPrivate(ip) || ip.IsLoopback() || isCloudMetadata(ip) {
        return error("目标地址不允许访问")
    }
}
// 禁止跟随重定向；若必须跟随，对每个跳转目标重新执行同样的 IP 校验

AWS IMDSv2：强制 Token 化——请求必须带 PUT 换取的 token，普通 GET 不再返回数据
            （阻断「一次 GET 拿凭证」的经典 SSRF 利用链）
阿里云/腾讯云：默认即需要请求头（如 metadata token 或 header 校验）
最佳实践：给所有出网请求加「禁止访问元数据地址」的网络层规则（如安全组/策略）

网络最小化：抓取/回源服务放在独立网段，只放行必要的出网规则
内网分段：即使 SSRF 发生，也摸不到核心数据库/管理面
最小权限：给抓取服务所在角色最低权限（无 IAM 写权限、无其他云资源访问权）
出网代理白名单：企业内网通过代理放行「白名单目标」，从源头阻断任意出网

经典代码：
  // ❌ 直接信任参数作为跳转目标
  redirect(request.getParameter("redirect_url"));

攻击场景：
  https://safe.example.com/login?redirect_url=https://evil.com/phish
  → 用户以为在安全站点，点击后被带到钓鱼站

危害（常被低估）：
  ① 钓鱼：跳转到仿冒登录页
  ② OAuth token 窃取：授权回调跳转被劫持，Authorization Code / Token 泄露给攻击者
  ③ 信任利用：用于构造「安全域名」的恶意链接，绕过邮件/IM 的域名信誉检查

✅ 白名单跳转：
  只在白名单域名/路径内跳转（如 /login?next=/dashboard，仅允许站内相对路径）
  站内跳转一律用相对路径或后端映射，不直接拼接用户输入
✅ 服务端统一处理：
  跳转目标由后端校验后再下发，前端不直接渲染用户可控 URL
✅ 若必须支持外链跳转：
  用「中间跳转页 + 二次确认」，或在跳转时校验目标 host 白名单

❌ 避免：
  直接 redirect(user_input)
  用正则只匹配开头（https://evil.com#https://safe.example.com 可绕过）

① 代码审计：grep 所有「取用户输入 → 发起 HTTP 请求」的代码路径
② 扫描：SAST（污点分析标记 URL 流向）+ 半自动 SSRF 检测（改 IP 看响应差异）
③ 手工验证：核心点必须人工验证
   - 输入本地/元数据地址，观察响应内容是否回显
   - 内网探测用「计时差异 + 状态码差异」确认连通

不要在生产盲扫内网网段（可能触发安全告警、打爆内部服务）；
在测试环境用「回显式」判断（如把目标改成自己可控的监听服务，
观察服务端是否真的回连），比盲扫更准确。