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段。