Raghav：开源 AI 框架漏洞从 SSRF 到 IDOR

开源 AI 框架进入企业生产环境的速度远远快于安全机制成熟的速度。安全工程师 Pranshu Raghav 用一句话概括了这种错位成熟生态里被视为理所当然的那些脚手架——正式的安全披露流程、定期的第三方审计、专职的安全维护者——根本没有时间长出来。Raghav 长期做应用安全、DevSecOps 与云安全曾为 Southwest Airlines、T-Mobile、Delta Air Lines、Verizon 等企业保障大型系统同时是 OWASP 基金会的活跃贡献者。他把「甲方一线」和「独立研究」两个视角叠在一起用「在日常保障大规模企业基础设施的过程中我能直接看到哪些开源 AI 框架真的被采用了、采用得多快以及框架承诺的能力和安全团队真正敢在生产环境里信任它所需要的条件之间缺口出现在哪里。」最值得警惕的一类问题是 agent 目标劫持agent goal hijacking恶意提示藏在文档元数据里不需要任何用户交互就能悄悄把企业敏感数据抽走。Raghav 认为在广泛部署之前主动清除这类威胁是掌握漏洞发现技能后自然产生的义务——「如果我能找到它们动机更差的人也能找到而两种结果之间的差别往往只取决于谁先看。」第二类是跨模态对抗攻击一个精心构造的输入就能在多租户系统的多个互联 agent 之间传播。Raghav 说这种爆发式扩张制造了前所未有的结构性空白。为建立安全基线新版软件成分目录开始加入特定的 schema 扩展用来追踪机器学习数据集的血缘关系——这类元数据恰恰是传统漏洞扫描器一贯忽略的。SSRF 与未认证的 MCP 服务器服务端请求伪造SSRF在现代 Web 架构里始终是个顽固威胁。近期针对流行开源接口的攻击表明HTTP 客户端在跟随重定向时不校验目标 URL就能让攻击者未经授权访问云元数据服务。Raghav 正是在测试平台如何处理外部资源引用——即允许服务器从用户提供的 URL 拉取资源的功能——时发现了同类问题。云环境中大量存在的未认证上下文处理服务器把这类漏洞的破坏力进一步放大。近期云安全研究显示MCPModel Context Protocol服务器在云环境中已经相当普遍其中相当一部分处于暴露状态或缺乏足够的认证控制。这些服务器一旦被操控就成了通往企业内部资产的直通车。「在云部署里这尤其危险因为它可以是取到元数据服务里云凭证的跳板然后用这些凭证继续向更大范围横向移动。」一个 IDOR牵动整条下游基础开发者平台处理大量专有数据租户隔离因此极为关键。缺少租户范围校验的缺陷会让无特权用户篡改绑定关系甚至发动针对检索增强生成RAG的拒绝服务攻击。Raghav 解释「IDOR 漏洞通常意味着只要改一下请求里的标识符——工作区 ID、应用 ID、文件引用——一个用户就能调出属于别人的资源中间没有任何授权检查。」还有攻击者利用 schema 解析器强制服务器发起任意的内部 HTTP 请求。由于这些平台高度集中「这一层上的一个访问控制缺陷可以级联到企业基于该平台构建的每一个下游 AI 应用」。合规风险随之放大监管机构会对被攻破的部署施以重罚而监管标准现在要求可追溯的 agent 监控与不可篡改的审计日志。披露经济学与「安全左移」开源工具中的严重漏洞修复往往不是改一行代码。不久前上下文测试工具集中披露的一个远程代码执行漏洞允许攻击者在工程师部署可用补丁之前执行任意代码。Raghav 承认这对独立开发团队是巨大压力核心功能可能需要重构「而小团队未必随时拿得出这种工程时间」。为此大型技术联盟宣布了定向拨款资助开源项目做独立安全审计和持续修复。另一个问题是资产可见性。企业很少孤立地使用开源框架——它们被接入内部数据源做 RAG、接入单点登录、拿到访问外部模型供应商的 API key。但只有很小一部分组织对自己在用的机器学习资产有完整可见性自动化追踪方案在开发流水线中的利用率极低。「很多组织部署得很快又没有完整的资产追踪一个存在漏洞的实例可能长期没人打补丁仅仅因为安全团队根本不知道它也属于自己的攻击面。」先进模型已经展示出自主发现遗留软件漏洞、并完成端到端控制流劫持的能力这超出了传统扫描器的模式匹配思路。Raghav 主张把安全左移到设计阶段威胁建模和访问控制评审要在设计时做而不是功能上线并积累用户之后再补。监管层面也在加码联邦指南要求机构厘清安全软件部署流程相关法案则强制开发者把密码学哈希映射到模型权重以维护数据溯源。需要说明的是这篇内容由 Jon Stojan 通过 HackerNoon 的 Business Blogging Program 分发属于观点型稿件而非独立调查报道。不过它指出的结构性矛盾——采用速度与安全投入之间的落差——在当前的开源 AI 生态里是真实存在的。