Taint Analysis for Graph APIs Focusing on Broken Access Control

本文提出了一种针对图 API 中访问控制失效问题的首个系统化静态与动态污点分析方法，该方法通过图转换规则建模 API 调用并利用关键对分析检测污点信息流，结合动态验证，在 GitHub GraphQL API 上成功识别了权限不足导致的访问受限及越权访问两类安全漏洞。

要点

这篇文章介绍了一种专门用来给图数据库接口（Graph APIs）“做体检”的新方法，目的是找出一种非常隐蔽且危险的漏洞：权限控制失效（Broken Access Control）。

为了让你轻松理解，我们可以把整个系统想象成一个巨大的、动态的“乐高城堡”，而这篇论文就是给这个城堡设计的一套智能安检系统。

1. 背景：什么是“图 API"？

想象一下，Facebook 或 GitHub 这样的网站，它们的数据不是像 Excel 表格那样一行行排列的，而是像乐高积木一样：

• 节点（Nodes）：是积木块（比如：用户、仓库、任务）。
• 边（Edges）：是连接积木的凸起和凹槽（比如：用户 A 拥有 仓库 B，仓库 B 包含 任务 C）。

这种“图”结构非常灵活，但也很难管理。传统的安检方法（像检查流水线上的盒子）在这里不管用，因为积木之间的连接千变万化。

2. 核心问题：权限失控（Broken Access Control）

在这个乐高城堡里，有些积木是**“机密积木”**（比如：仓库的删除权限、用户的私人信息）。

• 正常情况：只有持有“管理员钥匙”的人（Owner）才能移动或修改这些机密积木。
• 漏洞情况：一个只有“普通游客钥匙”的人（Collaborator），却意外地能移动这些机密积木，甚至把它们扔进垃圾桶。这就是权限失控。

3. 解决方案：污点分析（Taint Analysis）

作者提出了一种叫**“污点分析”的方法。你可以把它想象成给积木涂上“荧光油漆”**。

第一步：给积木“涂漆”（Setup / 设置阶段）

安全专家（安检员）先找出哪些积木是敏感的，给它们涂上红色的荧光漆（这就是“污点”）。

• 比如：在 GitHub 里，“仓库（Repository）”就是敏感积木，涂红漆。
• 然后，专家定义两类规则：
  • 源头规则（Source）：谁负责制造新的红色积木？（比如：创建新仓库的指令）。
  • 终点规则（Sink）：谁负责使用或修改红色积木？（比如：更新、删除仓库的指令）。

第二步：静态安检——“推演剧本”（Static Analysis / 静态分析）

这时候，我们不需要真的去操作积木，而是用计算机在脑海里**“预演”**所有可能的操作顺序。

• 核心工具：关键对分析（Critical Pair Analysis）。这就像是一个**“剧本冲突检测器”**。
• 它在找什么？ 它在找这样的剧本：
  1. 有人（规则 A）制造了一个红色积木。
  2. 紧接着（或者中间隔了几个无关动作），另一个人（规则 B）去修改了这个红色积木。
  3. 关键点：如果规则 B 执行时，操作者的身份没有管理员权限，但系统却允许他修改了，这就发现了潜在漏洞。

比喻：就像导演在排练前，检查剧本里有没有“小偷拿着钥匙直接打开金库”的情节。如果有，导演就会标记：“这里可能有漏洞，需要检查安保措施。”

论文的突破点：以前的方法只能发现“紧接着”发生的漏洞（直接漏洞）。但这篇论文发明了一种数学技巧，能发现**“隔山打牛”**式的漏洞（间接漏洞）。

• 例子：A 造了红积木 -> B 造了一个普通积木 -> C 把普通积木和红积木连起来 -> D 修改了红积木。
• 以前的方法会漏掉，因为 A 和 D 中间隔了 B 和 C。但作者证明，在特定条件下，通过数学推导，依然能发现这种链条中的漏洞。

第三步：动态安检——“实战演习”（Dynamic Analysis / 动态分析）

静态分析虽然聪明，但可能会“误报”（比如剧本里写了小偷，但现实中保安其实很严，小偷根本进不去）。所以，必须进行实战演习。

• 根据静态分析发现的“可疑剧本”，安全专家编写自动化测试脚本。
• 正测试：让有权限的人去操作，看能不能成功（应该成功）。
• 负测试：让没权限的人去操作，看能不能成功（应该失败，系统要报错）。
• 如果没权限的人居然成功了，那就实锤了：这里有一个真实的漏洞！

4. 实际应用：在 GitHub 上“抓鬼”

作者把这套方法用在了 GitHub（全球最大的代码托管平台）的 API 上。

• 案例 1：他们检查了“创建仓库”和“更新仓库”的流程，确认了权限控制是否严密。
• 案例 2（高光时刻）：他们复现了一个 GitHub 社区里真实存在的漏洞（Issue 106598）。
  • 漏洞描述：在某些特定的认证方式下，普通用户竟然能执行本该只有高级权限才能做的“代码分支对比”操作。
  • 结果：这套“荧光油漆 + 剧本推演 + 实战演习”的方法，成功自动发现了这个漏洞，并生成了复现脚本。

5. 总结：这套方法好在哪里？

1. 像侦探一样思考：它不只是看代码，而是看数据（积木）是怎么流动的。
2. 既看剧本又看现场：结合了“静态推演”（快、全面）和“动态测试”（准、实锤）。
3. 专门针对“图”结构：这是第一次有人系统地用这种方法去解决图数据库接口的权限问题。

一句话总结：
这就好比给乐高城堡装了一套智能监控系统，它不仅能给敏感积木贴上“易碎品”标签，还能在脑海里模拟所有可能的破坏路径，最后派“特工”去现场验证，确保没有任何一个没有钥匙的人能偷偷打开金库。

技术摘要

论文技术总结：针对图 API 的污点分析（聚焦访问控制失效）

1. 研究背景与问题 (Problem)

背景：
图 API（Graph APIs，如 GraphQL）基于图数据模型（节点代表数据对象，边代表关系）来管理 Web 应用程序的数据。随着其在社交网络、微服务和云计算中的广泛应用，其安全性变得至关重要。然而，由于图 API 相对新颖，现有的安全测试方法和工具尚不完善。

核心问题：
访问控制失效（Broken Access Control, BAC） 是 Web 应用中最突出的安全漏洞之一。在图 API 的语境下，BAC 表现为：

1. 过度授权： 用户（或攻击者）能够访问或操纵其无权访问/修改的数据。
2. 授权不足： 用户无法访问或操纵其本应有权访问/修改的数据。

现有的安全测试方法（如污点分析）通常针对传统 Web 应用，难以直接应用于基于图模型的 API，因为缺乏对图结构数据流和图操作（创建、更新、删除节点/边）的形式化建模。此外，现有的 BAC 检测方法往往缺乏系统性，难以同时支持污点分析、原生图形式化以及漏洞检测的完备性（Soundness）。

2. 方法论 (Methodology)

本文提出了一种针对图 API 的系统性污点分析方法，专门用于检测访问控制失效。该方法结合了静态分析和动态分析，并基于**图转换（Graph Transformation）**理论进行形式化建模。

2.1 核心流程

该方法包含三个主要阶段（如图 3 和图 7 所示）：

1. 设置阶段 (Setup)：

   • 形式化建模： 将图 API 的 Schema（如 GraphQL Schema）形式化为类型图（Type Graph, TG），将 API 调用（查询 Query 和变异 Mutation）形式化为图转换规则（Graph Transformation Rules）。
   • 污点标记 (Tainting)： 安全分析师根据策略，标记代表敏感数据的节点（如 Repository）。
   • 源与汇的识别：
     • 源规则 (Source Rules)： 创建敏感数据节点的规则（如 createRepo）。
     • 汇规则 (Sink Rules)： 读取或操纵敏感数据节点的规则（如 updateRepo, deleteIssue）。
   • 策略定义： 定义基于角色的访问控制（RBAC）策略，包括“策略预言机”（Policy Oracle，定义理论上谁可以做什么）和“策略实现”（Policy Implementation，实际代码中的权限检查）。

2. 静态分析阶段 (Static Analysis)：

   • 依赖分析： 利用关键对分析（Critical Pair Analysis, CPA）技术，自动计算源规则与汇规则之间的依赖关系（Dependencies）。
   • 污点信息流检测： 识别所有可能的污点数据流（即从创建敏感数据到使用该数据的潜在路径）。
   • 漏洞识别： 如果存在从源到汇的依赖，且该路径未被访问控制策略正确覆盖，则标记为潜在的 BAC 漏洞。
   • 完备性与局限性： 该方法对于直接的污点流（源后直接接汇）是完备且可靠的（Sound）。对于间接污点流（中间经过其他规则），在满足特定条件（如规则的可交换性/顺序独立性）下，也能通过归约到直接流进行检测。

3. 动态分析阶段 (Dynamic Analysis)：

   • 测试用例生成： 基于静态分析识别出的“未受保护的污点流”（Unsecured Flows）和“受保护的污点流”（Secured Flows），生成具体的测试脚本。
   • 执行与验证：
     • 正测试 (Positive Tests)： 使用具有足够权限的角色执行源和汇操作，预期成功。
     • 负测试 (Negative Tests)： 使用权限不足的角色执行汇操作（在源操作之后），预期失败（抛出权限异常）。
   • 结果判定： 如果正测试失败或负测试成功，则确认存在 BAC 漏洞。

2.2 关键技术点

• 图转换系统 (Graph Transformation Systems)： 使用双推（Double Pushout, DPO）方法形式化 API 调用，能够精确描述图结构的增删改。
• 粗粒度依赖分析 (Coarse-grained Dependency Analysis)： 使用 Henshin 工具进行关键对分析，识别最小依赖原因，平衡了分析的精度与效率。
• 覆盖准则： 提出了流覆盖 (Flow Coverage) 和 角色覆盖 (Role Coverage)，确保测试用例能够系统性地覆盖所有潜在的依赖关系和角色组合。

3. 主要贡献 (Key Contributions)

1. 首个系统性方法： 提出了首个针对图 API 的静态和动态污点分析框架，专门聚焦于访问控制失效（BAC）漏洞。
2. 形式化基础： 利用图转换理论将图 API 和污点分析形式化，为自动化分析提供了坚实的理论基础。
3. 混合分析策略： 结合了静态分析（用于发现潜在依赖和生成测试用例）与动态分析（用于验证实际实现），解决了静态分析在间接依赖检测上的不完备性问题。
4. 理论扩展：
   • 扩展了形式化模型以支持特定类型的间接漏洞检测（通过规则顺序交换和策略稳定性假设）。
   • 引入了角色覆盖 (Role Coverage) 概念，确保测试用例覆盖访问控制策略中的不同角色层级。
5. 工具实现与实证： 基于 Henshin 工具链实现了静态分析部分，并编写 Python 脚本进行动态测试。

4. 实验结果 (Results)

作者将该方法应用于 GitHub GraphQL API 的两个场景：

1. 扩展的运行示例 (Extended Running Example)：

   • 对简化的 GitHub 功能（仓库、项目、Issue）进行了建模。
   • 结果： 静态分析成功识别了多组源 - 汇依赖（如 createRepo -> updateRepo）。动态测试验证了 GitHub 现有的访问控制策略在这些场景下是正确实施的（即负测试成功拦截了未授权操作）。同时，发现了一个未文档化的依赖（createProject -> deleteProject），表明其访问控制是隐式实现的。

2. 真实漏洞复现 (Real-world Issue Reproduction)：

   • 目标： 复现 GitHub 社区论坛报告的问题 #106598。
   • 场景： 涉及 Ref 对象中的 compare 字段。问题在于：使用 OAuth 认证时，需要 repo 作用域才能进行比较；但使用细粒度令牌（Fine-grained token）时，即使没有 repo 作用域也能进行比较，导致权限绕过。
   • 过程： 构建了包含 Repository, Ref, Commit, Comparison 的污点类型图，并定义了相应的源/汇规则。
   • 结果： 动态分析脚本成功复现了漏洞。使用细粒度令牌（无 repo 作用域）的负测试意外成功（即未抛出权限错误），证实了 BAC 漏洞的存在。这证明了该方法能有效发现真实世界中的复杂权限绕过问题。

5. 意义与价值 (Significance)

• 填补空白： 解决了图 API 安全测试工具匮乏的问题，特别是针对 BAC 这一高危漏洞的自动化检测。
• 提升安全性： 提供了一种系统性的方法，帮助安全分析师在开发阶段发现并修复访问控制逻辑错误，防止数据泄露和未授权修改。
• 理论结合实践： 将形式化方法（图转换、关键对分析）与实际安全测试（污点分析、动态执行）紧密结合，既保证了理论上的严谨性（Soundness），又具备实际落地的可行性。
• 可扩展性： 该方法不仅适用于 GitHub，理论上可应用于任何可形式化为图转换系统的图 API（如 Neo4j Cypher, Amazon Neptune 等），为图数据库和图服务的通用安全测试提供了范式。

总结： 该论文通过引入基于图转换的污点分析框架，成功地将静态依赖分析与动态测试相结合，为检测和验证图 API 中的访问控制失效提供了一种高效、系统且理论上可靠的新途径。