SSRF是应用程序未对用户提供的URL或 URI 数据进行充分验证和过滤,导致攻击者可以操纵服务器向任意地址发起请求。由于其请求发自受信任的服务器内部,因此常可绕过网络边界的安全策略(如防火墙),访问到内部系统或元数据服务。
SSRF的检测通常是一个从黑盒到灰盒、从简单到复杂的流程。
第一阶段:侦察与信息收集
1.识别输入点
明显参数:查找任何接受URL、主机名或IP地址的参数,如 url=, host=, api=, endpoint=, file=。
隐藏参数:关注处理文件上传、下载、导入、转码、图像处理、链接预览等功能的接口。
HTTP头:检查 X-Forwarded-For, Host, Referer 等头部,某些应用会使用这些头部的值构建后端请求。
2.理解应用上下文
该功能是做什么的?是下载远程图片、获取网页内容、调用第三方API还是执行Ping检测?
观察正常请求的响应。服务器返回的是原始内容、处理后的内容还是仅显示成功/失败?这决定了后续利用的方式。
第二阶段:基础检测与漏洞确认
此阶段目标是确认服务器是否确实发起了对外请求。
1.使用外部监控服务
这是最有效、最安全且干扰最小的确认方法。
工具:使用 Burp Suite Collaborator、Interactsh 或自己搭建的DNSLog平台。
方法:将输入点的值替换为监控服务提供的唯一域名或URL。
如果监控服务收到了来自目标服务器的DNS查询或HTTP请求,即可确认存在SSRF。这适用于盲SSRF(无回显)场景。
2.回显检测
如果响应中会返回获取的内容,可以尝试让服务器访问一个已知的、可控的公共资源。
方法:请求 http://zmtests.com/get 或 http://zmtests.com/r/...,观察响应中是否包含了该网页的JSON内容(包含服务器的IP等信息)。
请求一个不存在的资源,观察错误信息是否泄露了网络信息(如连接超时、拒绝连接等)。
第三阶段:利用与绕过技巧
确认漏洞后,需评估其危害程度。
访问内部服务
1.经典方式:云元数据服务。这些服务通常位于无法从外网访问的链路本地地址。
AWS: http://169.254.169.254/latest/meta-data/
Google Cloud: http://metadata.google.internal/computeMetadata/v1/
Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01 (需要 Header: Metadata: true)
2.内网探测:尝试访问常见的内部网段地址和端口。
http://192.168.0.1:8080/admin
http://127.0.0.1:3306 (MySQL)
http://localhost:2379/version (Etcd)
3.协议处理绕过
应用程序的黑名单可能不完整,可尝试不同协议和技巧:
URL编码: http://127.0.0.1 -> http://%31%32%37%2e%30%2e%30%2e%31
十六进制/八进制编码: 127.0.0.1 -> 0x7f000001 (Hex) 或 0177.0.0.1 (Octal)
域名重定向:使用一个指向内部IP的域名 http://spoofed.burpcollaborator.net (A记录为127.0.0.1)。
非HTTP协议:某些库支持更多协议(需环境支持)。
file:///etc/passwd (读取系统文件)
dict://127.0.0.1:3306 (探测端口信息)
gopher:// (一个非常强大的协议,可用于构造任意TCP数据包,如Redis、MySQL未授权访问攻击)
4.短网址:将恶意URL转换为短链接以绕过过滤。
5.主机名混淆:
http://127.0.0.1:80@attacker-controlled.com/ (旧浏览器解析差异)
http://127.0.0.1#.attacker-controlled.com (利用URL fragment)
6.Open Redirection 结合
如果应用本身存在开放重定向漏洞(如 /redirect?url=https://google.com),可以尝试先指向该重定向端点,最终跳转到目标内网地址,以此绕过对“内部域名”的直接检查。
第四阶段:自动化辅助
工具:Burp Suite Professional 的 Active Scan 和 Collaborator 功能可以自动化检测常见的SSRF模式。
扩展:Burp插件如 SSRF Sheriff 可用于辅助检测。
自定义脚本:编写Python脚本,批量测试预定义的Payload列表和内部IP段。