引言
SSRF（Server-Side Request Forgery，服务端请求伪造）长期位居 OWASP Top 10 榜单，是一种危害被严重低估的 Web 安全漏洞。与 XSS、SQL 注入等传统漏洞不同，SSRF 的攻击面位于服务端与内网之间，攻击者可以借助存在漏洞的服务器作为跳板，穿透网络边界，访问本不可达的内部系统。在云原生架构普及的今天，SSRF 的危害进一步放大——攻击者可通过云厂商的元数据服务窃取临时凭证，进而接管整个云账号。本文将从原理出发，系统梳理 SSRF 的利用链路、常见绕过技巧以及防御策略。
一、SSRF 漏洞原理
SSRF 的本质是：服务端应用程序接收了用户可控的 URL 或主机参数，并在未做充分校验的情况下发起网络请求。由于请求由服务器发出，攻击者可以借此访问外网无法直接触达的资源。
常见的功能触发点包括：
- 图片/文件加载：如头像 URL 抓取、远程图片下载
- Webhook 回调：用户配置回调地址后由服务端发起请求
- URL 预览/爬虫：社交平台分享链接预览、在线网页抓取
- PDF/截图生成：将 HTML 渲染为 PDF 或图片时加载外部资源
- API 代理转发：服务端代理请求第三方接口
一个典型的脆弱代码如下：
import requests
from flask import Flask, request
app = Flask(__name__)
@app.route('/fetch')
def fetch():
url = request.args.get('url')
resp = requests.get(url) # 未做任何校验
return resp.text
攻击者只需传入 url=http://127.0.0.1:6379/ 即可探测内网 Redis 服务，或传入云元数据地址窃取凭证。
二、内网探测与服务识别
SSRF 利用的第一步通常是内网资产探测。攻击者通过构造不同协议和地址的请求，结合响应内容、响应时间、状态码等侧信道信息，判断内网存活主机与开放端口。
2.1 协议探测
不同协议对 SSRF 的利用价值差异巨大：
| 协议 | 利用场景 |
|---|---|
| http/https | 访问 Web 服务、云元数据 |
| file | 读取本地文件（如 file:///etc/passwd） |
| gopher | 构造任意 TCP 数据流，攻击 Redis、MySQL 等 |
| dict | 探测端口、与内网服务交互 |
| ftp/sftp | 文件传输与探测 |
其中 gopher 协议是 SSRF 中最强大的武器。它允许攻击者完全控制发送的 TCP 数据包内容，从而将 SSRF 升级为对 Redis、FastCGI、MySQL 等服务的攻击。例如，通过 gopher 向未授权 Redis 写入 SSH 公钥或计划任务，可直接实现 RCE。
2.2 端口与主机探测
攻击者常利用以下差异判断端口状态：
- 响应时间：开放端口通常响应更快，关闭端口可能超时
- 错误信息：
Connection refused与Connection timed out含义不同 - 响应内容：Banner 信息可暴露服务类型与版本
结合 Burp Suite Intruder 或自写脚本，可对内网 C 段进行批量扫描。
三、常见绕过技巧
当目标部署了 SSRF 防护（黑名单、白名单、正则过滤）时，攻击者会使用各种绕过手法。理解这些技巧对防御方同样重要。
3.1 黑名单绕过
（1）IP 地址变形
- 十进制：
http://2130706433/等价于127.0.0.1 - 八进制：
http://0177.0.0.1/ - 十六进制：
http://0x7f.0.0.1/ - 混合进制：
http://0x7f.1/ - 省略写法：
http://127.1/、http://0/
（2）DNS 重绑定
攻击者控制一个域名，首次解析返回合法 IP 通过校验，第二次解析返回内网 IP 完成攻击。这种手法可绕过基于域名解析的校验。
（3）URL 解析差异
不同语言和库对 URL 的解析存在差异。例如：
http://evil.com@127.0.0.1/——@前为认证信息http://127.0.0.1#@evil.com/—— 利用 fragment 解析差异http://127.0.0.1%09evil.com/—— 利用空白字符
（4）302 跳转绕过
若目标仅校验初始 URL，攻击者可让合法 URL 返回 302 跳转至内网地址，绕过白名单限制。
3.2 白名单绕过
白名单通常校验 URL 是否以特定域名开头。绕过方式包括：
http://allowed.com.evil.com/http://evil.com/allowed.com- 利用开放重定向：
http://allowed.com/redirect?url=http://127.0.0.1/
3.3 协议限制绕过
若仅允许 http/https，可尝试：
- 大小写混写：
HtTp:// - 协议相对 URL：
//127.0.0.1/ - 利用
file://变体读取文件
四、云元数据窃取：SSRF 的终极利用
在云环境中，SSRF 最致命的利用方式是访问云厂商的元数据服务（Metadata Service）。这些服务通常监听在链路本地地址，用于向实例提供临时凭证、配置信息等敏感数据。
4.1 主流云厂商元数据地址
| 云厂商 | 元数据地址 |
|---|---|
| AWS | http://169.254.169.254/latest/meta-data/ |
| 阿里云 | http://100.100.100.200/latest/meta-data/ |
| 腾讯云 | http://metadata.tencentyun.com/latest/meta-data/ |
| 华为云 | http://169.254.169.254/latest/meta-data/ |
| GCP | http://metadata.google.internal/computeMetadata/v1/ |
4.2 AWS IMDSv1 攻击链
对于启用 IMDSv1 的 AWS EC2 实例，攻击者可直接通过 SSRF 获取 IAM 角色的临时凭证：
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 CLI 配置这些凭证后，即可调用云 API，根据角色权限可能实现：
- 遍历并下载 S3 存储桶数据
- 创建新的 IAM 用户实现持久化
- 横向移动至其他云服务
- 甚至接管整个云账号
4.3 IMDSv2 的防护与绕过
AWS 推出 IMDSv2 以缓解此类攻击，要求请求携带通过 PUT 请求获取的 Token，且 Token 有 TTL 和跳数限制。这确实大幅提升了利用门槛，但并非绝对安全：
- 若应用本身支持 PUT 请求转发，仍可能获取 Token
- 部分 SSRF 场景可控制 HTTP 方法与头部
- 配置不当（如跳数限制过大）仍存在风险
因此，云厂商普遍建议强制启用 IMDSv2，并限制跳数（HttpPutResponseHopLimit=1）。
五、防御策略
SSRF 的防御需要纵深防御，单点措施往往可被绕过：
- 白名单优先：仅允许访问预定义的域名或 IP，避免使用黑名单
- 协议限制：仅允许 http/https，禁用 gopher、dict、file 等危险协议
- 禁止跳转：关闭自动重定向，或对跳转目标重新校验
- 解析后校验：先 DNS 解析，再校验 IP 是否属于内网段（注意防范 DNS 重绑定，需使用解析后的 IP 发起请求）
- 网络层隔离：通过防火墙、安全组限制应用服务器对内网和元数据的访问
- 云环境加固：强制启用 IMDSv2，限制元数据跳数，遵循最小权限原则配置 IAM 角色
- 统一出口代理：所有外部请求经代理转发，在代理层实施安全策略
结语
SSRF 之所以危险，在于它打破了网络边界假设——服务端本应可信，却成为攻击者的跳板。从内网探测到云元数据窃取，SSRF 的利用链路清晰且危害巨大。随着云原生架构的普及，SSRF 的潜在影响从单一应用扩展至整个云账号。对开发者而言，任何接受用户输入并据此发起请求的功能都应视为高危点，必须实施严格的白名单校验与网络隔离。对安全从业者而言，掌握 SSRF 的利用与绕过技巧，是评估云环境安全性的必备能力。
未经允许不得转载：任鹏个人博客 » SSRF 漏洞利用与绕过技巧：从内网探测到云元数据窃取
