希望成为一名 API 安全专家吗？

Byron McNaught of F5

高级解决方案营销经理

2023-03-16

本文转载自 The New Stack。

中国名将孙武在其兵书典著《孙子兵法》中说道：“知彼知己，百战不殆。”就网络安全而言，他的下一句话更为重要：“知己而不知彼，一胜一负。”

简而言之，要想了解您的敌人，您必须先成为自己的敌人。

安全专家深知维护 API 清单、及时了解风险态势的持续变化以及监控潜在安全风险的重要性。但是，要真正成为 API 安全专家，您需要从攻击者的角度思考，预测战术和技术，并制定安全防御措施来降低风险。

API Security Experts Train in the Art of Threat Modeling

OWASP

开放式 WEB 应用安全项目（OWASP）是一个致力于提高软件安全性的非营利性基金会，其标志性项目是 OWASP 十大 Web 应用安全风险列表。OWASP 还发布了一份十大 API 安全风险列表，列出了应用编程接口（API）面临的独特安全风险。

下面让我们详细了解一下在威胁建模过程中需要考虑的主要 API 安全防护风险：

风险	名称	描述
API1:2019	失效的对象级授权	攻击者通过操纵请求中发送的对象 ID 来利用 API 端点，这可能会导致数据泄露给未经授权方、导致数据丢失、数据操纵和完全账户接管。
API2:2019	失效的用户身份验证	攻击者将目标瞄准可能容易利用和滥用的身份验证组件，以获取对账户的控制、泄露敏感数据和执行欺诈性交易。
API3:2019	过度的数据暴露	如果 API 未能正确过滤，黑客可截获其返回的敏感数据。
API4:2019	缺乏资源和速率限制	攻击者滥用没有适当速率限制的 API，导致请求消耗网络、CPU、内存和存储等资源，造成拒绝服务（DoS），致使 API 无法响应甚至不可用。
API5:2019	失效的功能级授权	攻击者通过向其无权访问的端点发送合法的 API 调用来访问未经授权的功能，例如管理功能。
API6:2019	批量赋值	攻击者利用可自动将客户端的输入绑定到代码变量和内部对象的函数来更新或覆盖属性，从而实现权限升级、篡改数据和绕过安全机制。
API7:2019	安全配置错误	攻击者通过发现未打补丁的漏洞、通用端点或未受保护的文件和目录，获得对系统的未授权访问或了解，进而泄露敏感数据以及可能导致整个系统受损的详细信息。
API8:2019	注入	攻击者通过注入向量（比如直接输入、参数和集成服务）向 API 输入恶意数据，然后将这些数据发送到解释器并由解释器执行，从而导致信息泄露、数据丢失、DoS 或系统接管。
API9:2019	资产管理不当	攻击者利用存在漏洞/未打补丁的 API，企图访问敏感数据并可能接管系统。
API10:2019	日志记录和监控不足	攻击者利用日志记录和监控不足，偷偷滥用系统而不被察觉。由于正在进行的恶意活动不会被发现，因此攻击者有足够的时间全面入侵系统。

图 1 — OWASP 十大 API 安全防护风险

STRIDE 和 DREAD

Microsoft 创建了 STRIDE 方法。作为一种安全威胁模型，该方法可用于在设计阶段找出产品在生产环境中可能面临的威胁。

类别	描述
S	欺骗	冒充有效用户或资源以获取未经授权的访问。
T	篡改	修改系统或用户数据，无论是否被发现。
R	否认性	以无法跟踪的方式执行不受信任或非法操作。
I	信息泄露	泄露私人和/或关键业务信息。
D	拒绝服务	攻击系统，导致系统暂时不可用或无法使用。
E	权限提升	攻击者获得对系统的特权访问权限，从而入侵或破坏系统。

图 2 — STRIDE 方法

Microsoft 还有一种用于评估威胁的定性风险评估方法，称为 DREAD。

类别	对评级系统的影响
D	危害程度	攻击会造成怎样的危害？
R	复现难度	攻击能够轻松再现？
E	利用难度	成功发起攻击的难易程度如何？
A	受影响用户	有多少用户受到影响？
D	发现难度	这种威胁被发现的可能性有多大？

图 3 — DREAD 风险评估

OWASP、STRIDE 和 DREAD 可帮助您分析各种威胁场景。例如，OWASP 漏洞 API4:2019 “缺乏资源和速率限制”详细说明了攻击者针对未正确配置或根本未实施速率限制的 API 发动的几种场景。

在这张截图中，Microsoft STRIDE/DREAD 工具使用数据流图（DFD）来评估针对未实施速率限制的 API 网关的 DoS 威胁，揭示系统崩溃的高风险。

图 4：Microsoft 威胁建模工具

零信任分区

传统的分区网络架构或基于边界的网络设计采用安全“分区”的概念，其中安全“分区”是指网络中共享策略和要求的逻辑分组。该架构并非一个完全开放或扁平的网络，而是将基础设施服务划分为不同分区，通过控制攻击的“爆炸半径”来降低风险。

这种架构的一个主要特点是，分区内的所有用户和设备都会得到默许的信任，因此有权设置或更改分区的策略、要求及其他安全防护设置。

这类似于“城堡和护城河”防御。但是，再好的城堡和护城河也有可能被攻破。在涉及架构、云和企业职责的复杂现代环境中，盲目信任“企业边界”内用户和设备的传统方法已不再适用。安全防护正朝着零信任架构发展的原因之一就是要缓解攻击者攻破城墙的威胁。

零信任建立在“永不信任，始终验证”的基本前提之上，代表着向无边界安全防护的范式转变。没有绝对的信任，即使是获准越过网络护城河进入应用城堡的信使也不例外。

零信任要求对身份验证和授权进行持续评估，包括验证身份和完整性，而不依赖于用户类别（管理员、经身份验证/未经身份验证、合作伙伴）或设备位置等因素。其目的是根据风险等级，提供对应用、API 和服务的最低级别访问权限。

零信任的主要原则包括：

了解您的架构，包括用户、设备、服务和数据。
了解您的用户、服务和设备身份。
评估用户行为、设备和服务健康状况。
使用策略授权申请。
在各个位置进行身份验证和授权。
监控用户、设备和服务的所有访问。
不信任任何网络，包括您自己的网络。
选择和设计零信任服务。

通过采用零信任原则，API 安全专家能够支持零信任和分区网络架构，弥合本地和云系统之间的鸿沟，并在混合环境中实施一致的安全防护，例如采用可促进微分段的服务网格。

后续步骤

在打下坚实的基础后，包括 API 基础知识、管理和安全防护，我们就可以将这些概念付诸实践，通过面向云环境的重新构建来对传统应用进行现代化升级。请查看 O’Reilly 免费电子书《掌握 API 架构》中的假设案例研究，进一步探索如何将应用重新设计为 API 驱动型架构，并权衡云平台的运维和安全优势。