所有的 pull request 添加或更改 API 端点会改变 API 的攻击面。大多数 API 安全工具只有在端点上线并开始接收流量后才会发现问题。到那时,修复不再是代码审查中一行代码的修改就能解决的问题,而是需要进行事件响应讨论。
API 安全是指发现并消除应用程序公开其端点时存在的风险:谁可以调用它们,它们返回什么数据,以及它们是否按照文档所述执行操作。
目前针对此问题开发的大多数工具都是在运行时从外部测试 API,就像攻击者那样。这种方法虽然有效,但前提是 API 已经部署完毕。 西吉尼 它会走较早的路径:在发出任何请求之前,它会读取你的源代码和 API 规范。
测试 API 的四种方法,以及每种方法回答的问题
大多数成熟的程序都会运行其中不止一项:
- 静态测试 它会在部署前分析源代码和 API 规范,回答“我们刚刚暴露了什么?”这个问题。本文将重点介绍这种方法。
- 动态测试(DAST) 向正在运行的 API 发送真实流量并观察其响应。它回答了“目前哪些内容是实际可访问和可利用的?”这个问题。
- 模糊测试 它会向端点抛出格式错误或意外的输入,以暴露崩溃和极端情况下的故障。它回答了“在未预料到的输入下,哪些程序会崩溃?”这个问题。
- 手动渗透测试 它通过引入人工判断来发现自动化工具遗漏的逻辑缺陷。它回答了“一个聪明的攻击者会如何将各种逻辑漏洞串联起来?”这个问题。
这些方法彼此并不替代。它们在生命周期的不同阶段回答不同的问题,而大多数项目存在的不足之处在于第一个阶段。
为什么大多数 API 安全工具发现风险为时已晚
运行时 API 安全测试会向运行中的应用程序发送流量并观察其响应。这是一个合法且必要的安全层。但从本质上讲,它也是一种滞后指标:只有当端点存在、已部署且可访问时,运行时扫描器才能对其发出任何警报。扫描器发现的任何安全漏洞,在扫描运行期间都已经暴露在外。
除了上述时序问题之外,还存在第二个缺陷。运行时工具只能测试已知存在的内容。如果某个端点从未被记录,或者 OpenAPI 规范在新路由发布后立即过时,运行时扫描器就无法得知它的存在。它测试的是地图,而不是实际的路径。
静态 API 安全测试通过将检查移至定义端点的位置(即部署前的代码和 API 规范)来弥补这两个漏洞。 pull request 引入终点的是 pull request 这会暴露出其风险。
静态API安全性的真正含义
Xygeni 从两个来源构建您的 API 清单:您的应用程序源代码和您的 API 规范,包括 OpenAPI 和 Swagger。
仅包含规范的清单显示了有人记得记录的接口。仅包含代码的清单显示了已存在的功能,但不一定显示了它们的预期用途。同时阅读这两份清单才能获得完整的概览:包括团队记录的接口,以及无人记录的接口。
库存是其他一切的基础:
- 已发现的 API 总数以及与基线相比存在风险的资产
- 按 HTTP 方法细分的端点
- 按服务分组的问题
- 每个端点及其方法、路径、服务、模块、身份验证状态和风险评分
您的工程主管无需提交任何工单即可了解您的 API 架构。
Xygeni 找到的每个端点,包括其方法、身份验证状态和风险评分,都是根据代码和规范共同构建的。
Production note 从任何 API 安全屏幕截图中裁剪出 AI 分诊面板。
已映射到 OWASP API 安全 Top 10
调查结果与您的安全团队和审计人员已使用的框架相符。Xygeni 可检测 OWASP API 安全方面的风险。 10 强 (2023):
| OWASP | 风险 | 在实践中意味着什么 |
|---|---|---|
API1 | 损坏的对象级别授权 | 端点返回或修改属于其他用户或租户的数据 |
API2 | 未经认证的端点 | 无需任何身份验证即可到达某条路由 |
API3 | 过度数据暴露 | 响应返回的字段比调用者需要或应该看到的要多。 |
API3 | 大量分配 | 一个端点接受并应用了它原本不应该接受的字段。 |
API3 / API10 | 回复中包含敏感数据 | PII、PCI 或 PHI 从不应该发送它们的端点到达客户端。 |
API4 | 缺少速率限制 | 端点没有针对滥用或暴力破解调用的保护措施 |
API5 | 功能级别授权故障 | 端点执行特权操作时,未检查调用者是否具有该权限。 |
API7 | SSRF | 攻击者可以诱骗 API 代表其发出请求。 |
API8 | JWT配置错误 | 令牌验证、签名或过期设置不正确 |
API8 | CORS配置错误 | 跨域规则过于宽松,容易被利用。 |
API9 | 僵尸和孤儿端点 | 已弃用或已被遗忘但仍可访问的路由,以及无人拥有的路由。 |
有一个类别被刻意忽略了。API6,即“对敏感业务流程的无限制访问”,需要理解业务流程应该允许什么,而任何静态分析器都无法可靠地检测到这一点。任何声称可以做到这一点的供应商,都只是在兜售一个复选框而已。这个复选框应该由你的威胁建模人员和渗透测试人员来处理。
并非所有发现都同等重要:数据敏感性和毒性组合
如果将未经身份验证的健康检查端点与返回客户记录的未经身份验证的端点视为同一类问题,那么列表式的检查结果实际上并不相同。如果优先级模型对它们采用相同的评分标准,就会让团队养成忽略该列表的习惯。
Xygeni 对每个端点处理的数据进行分类,在请求参数和响应中标记 PII、PCI 和 PHI,并将其与端点的身份验证状态配对。
它还会关联出现在同一端点上的发现,并在发现多个此类问题时提高严重程度。响应中的个人身份信息泄露本身就是一个严重的问题。同样,在无需身份验证的端点上发生的泄露则更为严重,平台会根据具体情况进行评分,而不是让用户手动发现连接问题。
僵尸端点和孤儿端点:代码与规范之间的鸿沟
由于 Xygeni 会并排读取您的代码和 API 规范,因此它可以发现它们之间的差异。这种差异会以三种可识别的模式表现出来:
- 未记录的端点。 它们存在于代码中,从未被添加到规范中。
- 僵尸终点站。 它们被标记为已弃用或已停用,但仍然可以访问。
- 孤立端点。 目前球队中没有人拥有这些球衣。
这些都不会出现在仅包含规格的清单中,因为规格本身就缺少它们。
您可以采取行动的证据,而不是需要调查的罚单
每一项发现都指向负责的具体处理程序:文件、类、方法以及引入缺陷的具体代码行,并附有相应的错误代码。每一项发现还包含其严重程度、OWASP API 安全 Top 10 类别、CWE 编号、端点的身份验证状态以及所涉及数据的敏感度分类。
如果只是指出某个端点,开发人员就得在代码库中到处查找才能开始修复。如果直接指出是哪一行代码,他们就能立即找到修复方法。
研究结果以 JSON、CSV、Markdown 和 SARIF 2.1.0 格式导出,因此它们会保存在 t 目录中。团队已经在使用的工具。
处理程序、行号以及引入漏洞的代码。无需提交工单进行调查。
为什么它只存在于一个平台,而不是另一个主机平台?
Xygeni 同时运行 API 安全 SAST, SCA, 机密安全, IaC 和 达斯特 在单一平台内,通过以下方式关联 ASPM而不是将其作为单独的工具发布。 login 以及它自身的积压工作。
这一点很重要,因为静态检测结果和运行时检测结果针对的是同一个端点的不同问题,而且它们结合起来比单独使用更有用。静态检测结果会在端点上线前就指出其风险。而运行时安全测试 (DAST) 则会在端点运行后确认其实际可访问性和可利用性。
将相关风险分散到两个控制台,就变成了两个互不相关的待办事项。没有人会协调它们,而那个既没有文档记录又未经身份验证的端点,既不在任何一个待办事项列表中。
查看您真实的 API 攻击面。 API 安全性可作为一项功能提供。 Enterprise Xygeni 平台的一个附加组件,会对您自己的基础设施内的您自己的存储库进行扫描。
常见问题解答
它能否识别哪些端点处理敏感数据?
是的。Xygeni 会在终点参数和反应中标记 PII、PCI 和 PHI,并使用该分类按实际暴露情况对结果进行排序。
它能在所有设备上运行吗? pull request?
是的。增量扫描仅分析已更改的端点,并且它生成的清单可以将后续的 DAST 扫描集中在这些相同的端点上,因此静态和运行时测试与实际更改的内容保持一致。
我的代码会离开我的环境吗?
不。扫描在您自己的基础设施上运行。只有结果会被上传,并在传输和存储过程中受到保护。
如何获得 API 安全性?
API 安全性可作为一项功能提供。 Enterprise 附加组件。请申请概念验证,我们会与您共同确定范围。





