GET /subscriptions/.../extensions/proxy/path/%2e%2e/%2e%2e/%2e%2e/%2e%2e/apim/keyvault/fd8d0f4f.../secrets/victimsecret/value HTTP/1.1{
"value": "dontreadme"
}4 个未加转义的相对路径符号 %2e%2e，撬开了租户大门。另一个租户存放在 Azure Key Vault 中的密钥明文，被直接调了出来。返回的一行 JSON 数据，拉开了公有云跨租户漏洞挖掘的序幕。
2026 年 10 月，挪威机构 Binary Security 披露了 Azure Logic Apps 的攻防成果。研究员连续挖出 5 个高危跨租户提权漏洞，累计获得微软 20 万美元赏金。厂商对同一模块持续开出顶格赏金。跨租户隔离失效直接击穿了公有云的信任底线。
在这场长达数月的拉锯中，研究员每突破一次，微软就追加一层过滤规则。多租户隔离防线退化成了疲于奔命的正则表达式。整个系统把后端高特权凭据集中托付给共享代理，这才是隐患的根源。
共享代理代持凭证，租户隔离退化为字符串比对
Azure Logic Apps 是企业级工作流平台，通过 API Connections 连接下游服务。受支持的系统涵盖 Key Vault、Azure SQL 以及 Jira 与 Salesforce。它的集成边界几乎没有上限。为了帮开发者简化鉴权，微软设计了一套集中式代理架构。
Logic App 将全部外部请求交由共享的 APIM 实例统一处理。共享 APIM 统一代管全网租户的连接机密。它在网关层执行令牌交换，把调用方请求置换为真实的后端凭证。这套共享代理因此成了打开所有租户后端大门的特权枢纽。
图：微软官方架构文档中的 API Connections 设计。Logic App 借助共享 APIM 交换令牌并访问下游服务。来源：Binary Security
微软官方架构图省略了一条通向共享代理的内部路径。ARM 平台暴露了 DynamicInvoke 与 /extensions/proxy/ 端点。它们允许调用方绕过前端编排，直接向底层代理发送请求。请求进入 APIM 后，下游服务已无法辨识调用方的真实租户身份。
多租户隔离防线退化为 URL 路径匹配，缺乏密码学或沙箱级别的强隔离。 代理网关在解析入站字符串时只要出现微小误差，就会按规则替请求签名。受害者的后端资源随后会被全盘导出。
4 层路径跳转直接越权，黑名单漏掉 4 个兄弟接口
首个漏洞触发点位于 ARM 的 DynamicInvoke 内部接口。研究员在自身订阅内创建了合法的 Key Vault 连接。他借由 4 次 URL 编码的 %2e%2e 向上跳转，直接切入受害者租户所属的资源路径。
图：跨租户读取受害者 Key Vault 敏感数据的运行时响应。来源：Binary Security
APIM 网关收到请求后直接展开相对路径。它调取受害者的预置凭证访问目标密钥库，回传了代号为 dontreadme 的机密。研究员凭借这一路径跳跃在 2025 年 8 月拿到了 4 万美元首期赏金。核心代理组件缺乏基础的路径规范化校验，暴露出输入防御上的严重松懈。
MSRC 迅速部署了首轮补丁。团队在 DynamicInvoke 入口加入了针对相对路径的黑名单过滤。这种局部修补促使研究员深入探寻架构盲区。他申请了一台独占主机的 Standard Logic App，通过 SSH 提取并反编译了运行时组件。
在受修补的 DynamicInvoke 旁边，并排挂载着 4 个未公开的同族方法。它们是 DynamicList、DynamicCreate、DynamicUpdate 与 DynamicDelete。首轮补丁只堵住了被报告的那扇门。其余 4 个具备写操作能力的接口，继续在共享代理上裸露。
研究员借助未设防的 DynamicList 接口向受害者的 Azure SQL 数据库注入了指令。他成功写入了恶意数据记录：Insert INTO MySecrets VALUES ('NewEvilSecrets', 3)。跨租户攻击由此从被动窃听升级为主动数据篡改。只对单个接口做点状修补，必然会导致安全防线被同源逻辑再次攻破。
V1 架构缺乏身份绑定，全网连接默认共享
为什么攻击者能随意调用任意租户的连接？答案深植于 Azure 两代连接体系的历史架构差异中。Logic App 分为消费型模式与独立主机模式。两者创建的连接分别对应 V1 与 V2 两套规范。
在 Standard 模式的 V2 架构中，系统为调用方分配托管标识。调用方通过强校验的数字凭证向后端发起认证。但在早期设计的 V1 体系中，计算节点没有独立的身份凭据。V1 连接建立之后，系统在调用者维度没有实施任何身份绑定策略。
图：V1 连接创建机制。Consumption Logic App 无可授权身份，导致连接缺乏调用方绑定。来源：Binary Security
身份绑定的缺位造成了一个惊人的系统状态。全网所有企业建立的 V1 连接，在代理层默认向所有应用开放。任何租户发来的合法请求，都能直接索取该连接的执行代理权。阻隔跨租户调用的唯一屏障，只剩下请求参数是否与规则字面相符。
研究员在反编译代码中找到了关键参数 host.api.RuntimeUrl。代理逻辑在核验前端参数后，允许请求改用动态地址转发。只要目标主机以后缀 azure-apihub.net 结尾，网关就会自动附加受害者的 Authorization 认证头。
校验跑在规范化前面，修复补丁连续 3 次被穿
面对 RuntimeUrl 带来的伪造风险，微软发布了第二轮防御补丁。团队加入了严格的白名单比对，要求请求主机名与预置连接保持一致。然而这道看似缜密的规则，却在执行时序上犯了致命错误。
安全比对被错误地放在了路径规范化之前执行。校验模块只检查原始字符串，判定目标依然属于攻击者自己的目录。负责转发的代理网关随后展开了相对路径，实际请求再次打入受害者资源。
比对时序与解析时序的错位，直接瓦解了白名单规则的防御力。 攻击者利用模块间对 URL 理解的时序差异，重新夺回了控制权。这枚绕过漏洞再次触发了微软的高额赏金发放。
连环漏洞的戏剧性在随后的修补中达到顶点。微软在重构分支代码时，意外移除了原本加在 RuntimeUrl 上的校验逻辑。攻击路径在第五次测试中死灰复燃，跨租户提权通道再次敞开。高频失效的修补表明，单纯依靠外围文本过滤无法筑起稳定的安全体系。
凭据放错层级，单靠正则修不好多租户系统
在研究员与 MSRC 的持续协作下，微软最终重构了核心路由逻辑。双方在沟通细节上偶有分歧，但整体维持了高效透明的响应机制。全部 5 枚高危漏洞在 2026 年 Blue Hat Asia 峰会前夕获得修复。这场长达一年的攻防交锋就此画上句号。
研究员在总结报告中给出了严肃的工程判断。当前修复主要依靠截断路径，端点一旦重新暴露仍缺乏后置防护。API Connections 默认使用建立者的个人 Token，企业极少做权限收窄。这种过度宽松的授权配置，让越权访问的破坏力成倍放大。
多租户公有云的安全屏障必须建立在端到端身份绑定上。集中式转发层的事后审查无法承担最终防线的重任。高特权凭据只要托管在缺乏上下文的共享代理中，防线就会受制于解析偏差。把凭据收束在具备独立身份的计算沙箱之内，才是消除跨租户隐患的可靠基石。
参考链接：
- Binary Security 技术分析：One Root Cause to Rule Them All
- MSRC 安全漏洞致谢与修复公告
- Blue Hat Asia 2026 安全峰会演讲纪要
