写在前面：合法学习边界
SSRF 测试只允许在自建靶场或授权环境进行。对真实系统做内网探测、读元数据可能触犯法律。
一、漏洞原理
SSRF（服务端请求伪造）指服务器根据用户提供的 URL 发起请求。攻击者让服务器去访问原本到不了的地方。
1
| curl 场景：URL 预览、截图、webhook、图片代理、文件下载
|
如果 URL 可控且无限制，服务器就成了攻击者的“跳板”。
二、影响与危害
1
2
3
4
5
| 读取内网文件（file://）
探测内网端口与服务
访问云元数据（169.254.169.254 的 IAM 密钥）
配合 Redis/内网组件 Getshell
绕过 WAF/网络隔离
|
风险等级：高到严重。
三、利用 / 复现
读文件
1
2
| file:///etc/passwd
file:///C:/Windows/win.ini
|
探测内网
1
2
3
| http://127.0.0.1:80
http://10.0.0.1:6379
http://192.168.1.1:8080
|
通过响应差异判断端口是否开放。
云元数据
1
2
3
4
5
| # AWS
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
# 阿里云
http://100.100.100.200/latest/meta-data/
|
拿到临时凭证即可接管云资源。
配合 Redis Getshell
见本站《漏洞联动：SSRF 打内网 Redis 未授权 Getshell》：
1
| SSRF → gopher 到 6379 → CONFIG 写 crontab/WebShell
|
常见绕过
1
2
3
4
| 127.0.0.1 → 2130706433、[::1]、十进制/十六进制
localhost → 绕过域名黑名单
@ 与 # 混淆、重定向绕过
DNS 重绑定
|
复现操作步骤
1
2
3
4
5
| 第 1 步：找 URL 可控点（预览/代理/下载功能）
第 2 步：试 file:///etc/passwd —— 读到即文件读取
第 3 步：试 http://127.0.0.1:6379 或内网端口 —— 端口差异判断
第 4 步：云环境试 169.254.169.254 元数据
第 5 步：配合 Redis/元数据确认影响面
|
四、检测
1
2
3
4
| 参数中 URL 可控且协议未限制
请求目标出现内网地址/云元数据
异常出站请求与响应差异
日志中 file://、169.254、内网 IP 请求
|
五、防御
1
2
3
4
5
| URL 白名单（只允许预期域名/IP）
禁止内网段与元数据地址
禁用 file/gopher/dict 等协议
禁用自动重定向
限制请求大小与频率
|
六、修复
1
2
3
4
| 服务端校验并归一化 URL
解析后校验 IP（防 DNS 重绑定）
按协议白名单放行
修复后复测：内网与元数据访问被阻断
|
七、小结
SSRF 的价值在于“借力打力”：让服务器替你去访问内网。配合 Redis、云元数据，单点 SSRF 就能变成 Getshell 或云接管。它是漏洞链里最好的“入口跳板”。