网络安全等级保护：了解API安全要素

API安全要素

一个API本质上定义了一组允许调用者使用的操作。如果不希望用户执行某些操作，只需将其从API中排除即可。那么为什么我们需要关心API安全性呢？

·首先，具有不同权限级别的用户可以访问相同的API；例如，某些操作仅允许管理员或具有特殊角色的其他用户执行。API还可能会暴露给互联网上根本不应该有任何访问权限的用户（和机器人）。如果没有适当的访问控制，任何用户都可以执行任何操作，这可能是不受欢迎的。这些是与API必须运行的环境相关的因素。

·其次，虽然API中的每个单独操作本身可能是安全的，但操作组合可能不安全。例如，银行API可能提供单独的取款和存款操作，分别检查是否未超出限额。但存款操作无法知道存入的资金是否来自真实账户。更好的API可以提供转账操作，通过一次操作将资金从一个账户转移到另一个账户，从而保证始终存在相同数量的资金。API的安全性需要作为一个整体来考虑，而不是单独的操作。

·Zui后，由于API的实现可能存在安全漏洞。例如，如果未能检查API输入的大小，攻击者可能会通过发送消耗所有可用内存的非常大的输入来关闭您的服务器；一种拒绝服务 (DoS) 攻击。

定义拒绝服务 (DoS) 攻击发生在以下情况：攻击者可以阻止合法用户访问服务。这通常是通过用网络流量淹没服务，阻止其服务合法请求来完成的，但也可以通过断开网络连接或利用错误使服务器崩溃来实现。

一些API设计比其他设计更适合安全实施，并且有一些工具和技术可以帮助确保安全实施。在开始编码之前考虑安全开发比等到稍后在开发或生产中发现安全缺陷要容易得多（也便宜）。回顾性地改变设计和开发生命周期以考虑安全性是可能的，但并不容易。

重要的是要记住，不存在完美安全的系统，甚至没有单一的“安全”定义。对于医疗保健提供者来说，能够发现朋友是否在系统上拥有账户将被视为重大安全缺陷和隐私侵犯。然而，对于社交网络来说，同样的能力是一个必不可少的特征。因此，安全性取决于上下文。设计安全API时应考虑很多方面，包括：

·需要保护的资产，包括数据、资源和物理设备

·哪些安全目标很重要，例如账户名的机密性

·可用于实现这些目标的机制

·API运行的环境以及该环境中存在的威胁

2023年API安全TOP 10

以下是 2023 年版本的预览：

API1:2023 - 对象级授权被破坏

API 往往会公开处理对象标识符的端点，从而造成对象级访问控制问题的广泛攻击面。在使用用户 ID 访问数据源的每个函数中都应考虑对象级授权检查。

API2:2023 - 身份验证损坏

身份验证机制通常实施不正确，从而使攻击者能够破坏身份验证令牌或利用实施缺陷暂时或yongjiu冒用其他用户的身份。损害系统识别客户端/用户的能力，就会损害 API 的整体安全性。

API3:2023 - 损坏的对象属性级别授权

该类别结合了API3:2019 过多的数据泄露和 API6:2019 - 批量分配，重点关注根本原因：对象属性级别的授权验证缺乏或不正确。这会导致信息暴露或被未经授权的各方操纵。

API4:2023 - 无限制的资源消耗

满足API请求需要网络带宽、CPU、内存和存储等资源。其他资源（例如电子邮件/短信/电话或生物识别验证）由服务提供商通过 API 集成提供，并按请求付费。成功的攻击可能会导致拒绝服务或运营成本增加。

API5:2023 - 功能级别授权被破坏

具有不同层次结构、组和角色的复杂访问控制策略，以及管理功能和常规功能之间不明确的分离，往往会导致授权缺陷。通过利用这些问题，攻击者可以访问其他用户的资源和/或管理功能。

API6:2023 - 无限制访问敏感业务流程

易受此风险影响的 API 会暴露业务流程（例如购买门票或发表评论），而不会补偿该功能如果以自动化方式过度使用可能对业务造成的损害。这不一定来自实施错误。

API7:2023 - 服务器端请求伪造

当 API 在未验证用户提供的 URI 的情况下获取远程资源时，可能会出现服务器端请求伪造 (SSRF) 缺陷。这使得攻击者能够强制应用程序将精心设计的请求发送到意外的目的地，即使受到防火墙或 VPN 的保护也是如此。

API8:2023 - 安全配置错误

API 和支持它们的系统通常包含复杂的配置，旨在使 API 更加可定制。软件和 DevOps 工程师可能会错过这些配置，或者在配置时不遵循安全zuijia实践，从而为不同类型的攻击打开了大门。 

API9:2023 - 库存管理不当

API 往往比传统 Web 应用程序公开更多端点，因此正确且更新的文档非常重要。正确的主机清单和已部署的 API 版本对于缓解诸如已弃用的 API 版本和暴露的调试端点等问题也很重要。

API10:2023 - API 的不安全使用

开发人员更倾向于信任从第三方 API 收到的数据，而不是用户输入，因此倾向于采用较弱的安全标准。为了破坏 API，攻击者会寻找集成的第三方服务，而不是尝试直接破坏目标 API。