Web View

_book/Chapter10/10-1.md

@@ -0,0 +1,28 @@
+### 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 凭证来控制整个云实例