SSRF 漏洞存在位置

1. URL地址加载资源

这是 SSRF 漏洞最经典的藏身之处。当一个网站需要通过 URL 地址从其他服务器获取图片、文件或音频等资源时，就可能存在 SSRF

• 头像/图片上传：很多社交平台或电商网站允许用户通过提供图片 URL 来上传头像或商品图片
  • 案例：在某电商平台的商品图片上传接口，我发现一个名为 image_url 的参数。我将其值从一个合法的图片链接改为内网地址，如http://192.168.1.1，服务器返回了连接超时的错误。当我改为http://127.0.0.1:80 时，却返回了“HTTP 请求无效”的错误。通过这些差异，我判断 127.0.0.1 的 80 端口是开放的，从而证实了 SSRF 漏洞的存在
• 文章或图片收藏：当用户分享或收藏一个网页时，服务器会去抓取页面标题、描述、缩略图等信息
  • 案例：在一个内容管理系统（CMS）中，我测试了“分享文章”功能。当我输入一个 URL 时，系统会生成一个预览。我将 url 参数的值从外网地址改为了 http://localhost/，结果系统成功抓取并展示了本地服务器的登录页面。这证明了服务器执行了请求，并且没有对 localhost 进行过滤

2. URL协议解析不当与转码服务

开发者在处理 URL 时，往往只过滤了 http:// 和 https://，却忘记了其他协议，或者没有对 URL 重定向进行二次校验

• 转码服务：一些在线视频或音频转码服务，需要用户提供一个 URL，服务器会去下载并进行格式转换
  • 案例：一个视频转码服务的 video_url 参数可以被利用。我尝试将 http:// 协议替换为 file://，并输入 file:///etc/passwd。服务器返回了 /etc/passwd 文件的内容，这表明服务器不仅存在 SSRF，还存在**本地文件读取（LFI）**漏洞
• 在线翻译/API调用：许多翻译服务需要通过 API 去获取内容，如果 API 的 URL 可控，就可能存在 SSRF
  • 案例：一个未公开的 API 接口用于调用 URL 服务，我尝试用 gopher:// 协议去攻击内网的 Redis 服务。我构造了 Gopher URL，并将其作为 API 参数发送，最终成功在目标服务器上执行了 Redis 命令，实现了代码执行

3. 第三方服务与Webhooks

现代应用经常需要与其他服务集成，例如支付接口、云服务 API 等。这些集成点经常需要通过 URL 进行通信

• Webhooks：许多 SaaS 产品支持 Webhooks，当特定事件发生时，它会向用户指定的 URL 发送 HTTP 请求
  • 案例：在一个 Git 仓库管理平台，我发现它允许自定义 Webhook URL。我将 Webhook URL 设置为内网的 http://192.168.10.20/。当有代码提交时，我通过检查网络流量，证实了服务器确实去请求了这个内部地址，从而证明了 SSRF 漏洞的存在
• 云服务API：在云环境中，元数据服务通常通过一个固定的内网 IP 提供敏感信息
  • 案例：在一个运行在 AWS 的网站上，我利用 SSRF 漏洞让服务器请求 AWS 的元数据服务地址http://169.254.169.254/latest/meta-data/。服务器成功返回了一个目录列表，这表明我能够访问这个特殊的内网服务，并可以进一步获取 IAM 凭证来控制整个云实例

版权所有

许可证：署名 4.0 国际 (CC-BY-4.0)