API 安全性与一般应用程序安全性有何不同？

已发表: 2023-07-19

尽管有时会混淆，但应用程序安全性和 API 安全性是两个不同的学科。 应用程序安全性是指保护整个应用程序的安全，而 API 安全性是指保护组织用于连接应用程序和交换数据的 API 的安全。 因此，组织必须对这两个学科采取不同的方法。

什么是应用程序安全性？

应用程序安全 (AppSec) 使用授权、加密和安全编码实践来保护数据和系统免受网络攻击。 实施 AppSec 的组织可以降低数据泄露的风险、保护敏感数据并确保其应用程序符合行业标准。

ISACA 将 AppSec 计划的五个关键组成部分定义为：

  1. 安全设计
  2. 安全代码测试
  3. 软件物料清单
  4. 安全培训和意识
  5. WAF和API安全网关和规则开发

什么是 API 安全性？

API（即应用程序编程接口）安全性可保护 API 免受网络攻击。 近年来，API 的使用呈爆炸式增长，通过支持应用程序之间的数据传输为组织提供了创新机会。 不幸的是，随着 API 使用的增加，针对它们发起的攻击也随之增加。 Salt Security 的研究显示，2022 年 6 月至 12 月期间，针对 API 的攻击增加了 400%。

应用程序与 API 安全威胁

了解 AppSec 和 API 安全性之间的差异需要了解每个学科的主要威胁。 幸运的是，OWASP（一个致力于提高软件安全性的非营利组织）提供了应用程序安全和 API 安全性最重要威胁的完整列表。 该列表被称为 OWASP 十大，整理了 OWASP 全球安全专家社区的信息，以确定对应用程序和 API 的最严重威胁。

有趣的是，虽然 OWASP 于 2003 年发布了十大 Web 应用程序安全风险列表，但它在 2019 年底才发布了十大 API 安全风险列表。这种差异代表了应用程序安全和 API 安全之间的另一个关键区别：应用程序安全性是一个公认的、这是一个经过广泛研究的学科，经历了许多演变阶段，而 API 安全则不然。

虽然我们没有时间进行深入分析，但值得简要查看每个列表以了解它们有何不同，这应该告诉组织如何处理 AppSec 和 API 安全性。

OWASP 十大应用程序安全风险 (2021)

  1. 访问控制被破坏– 当未经授权的用户可以访问受限制的信息或系统时
  2. 加密失败– 当第三方由于加密缺乏或缺陷而在没有特定意图的情况下公开敏感数据时
  3. 注入– 当攻击者尝试以改变发送到解释器的命令含义的方式向应用程序发送数据时
  4. 不安全的设计——与架构和设计缺陷相关的风险
  5. 安全配置错误– 当安全团队配置不准确或安全控制不安全时
  6. 易受攻击和过时的组件– 当组织未对组件进行修补时
  7. 识别和身份验证失败（即身份验证损坏） ——当应用程序容易受到身份验证攻击时
  8. 软件和数据完整性故障——当代码和基础设施无法防止完整性违规时
  9. 安全日志记录和监控失败（不充分的日志记录和监控） ——当组织由于日志记录和监控程序不充分而无法检测到数据泄露时
  10. 服务器端请求伪造– 当攻击者欺骗应用程序将精心设计的请求发送到意外目的地时，即使受到防火墙、VPN 或其他类型的网络访问控制列表 (ACL) 的保护

OWASP 十大 API 安全风险 (2023)

  1. 对象级授权被破坏– 当 API 对象（例如数据库或文件）没有适当的授权控制时，会授予未经授权的用户访问权限
  2. 身份验证失效– 当软件和安全工程师误解 API 身份验证的边界以及如何实施时
  3. 损坏的对象属性级别授权– 过度数据暴露和大量分配的组合：当攻击者利用对象属性级别的锁定或不当授权时。
  4. 无限制的资源消耗 –满足 API 请求需要网络带宽、CPU、内存和存储。 服务提供商通过 API 集成提供其他资源，例如电子邮件/短信/电话或生物识别验证，并按请求付费。 成功的攻击可能会导致拒绝服务或增加运营成本。
  5. 破坏功能级授权涉及攻击者向暴露的 API 端点发送合法的 API 调用
  6. 无限制地访问敏感业务流程——易受此风险影响的 API 会暴露业务流程（例如购买门票或发表评论），而不会补偿如果以自动化方式过度使用该功能可能对业务造成的损害； 这不一定来自实施错误。
  7. 服务器端请求伪造 –当 API 在未验证用户提供的 URI 的情况下获取远程资源时； 使攻击者能够强制应用程序将精心设计的请求发送到意外的目的地，即使受到防火墙或 VPN 的保护也是如此。
  8. 安全配置错误——API 和支持它们的系统通常包含复杂的配置，以使其更具可定制性。 软件和 DevOps 工程师可能会错过这些配置，或者不遵循有关配置的安全最佳实践，从而为不同类型的攻击打开了大门。
  9. 不正确的库存管理– API 比传统 Web 应用程序公开更多端点，因此正确且更新的文档非常重要。 充足的主机和已部署的 API 版本清单对于缓解诸如已弃用的 API 版本和暴露的调试端点等问题也至关重要。
  10. API 的不安全使用——开发人员倾向于信任从第三方 API 接收的数据，而不是用户输入，并采用较弱的安全标准。 为了破坏 API，攻击者会寻找集成的第三方服务，而不是尝试直接破坏目标 API。

正如您所看到的，虽然存在一些重叠，但应用程序和 API 主要受到不同的、独特的威胁，组织必须做出相应的响应。 这两个列表之间的主要区别在于，组织可以使用传统的多用途安全工具和技术来缓解与应用程序安全相关的所有关键风险，但 API 安全性有所不同。

API 安全是一个高度现代的问题，需要同样现代的解决方案。 组织不能指望他们用来保护应用程序和其他资产的工具能够满足保护 API 的任务。 API安全需要API专用的安全工具； API 网关和 Web 应用程序防火墙 (WAF) 等传统保护方法还不够。