主要的 API 安全风险以及如何缓解它们

在微服务的大量兴起和快速部署应用程序的不断推动下，API 已成为每个企业家的首选名称。

然而，随着每个小功能都与其他软件或产品链接以获得无缝的用户体验，API 正日益成为安全黑客的中心。 以至于 Gartner 的《如何建立有效的 API 安全策略》报告预测，到 2022 年， API 安全风险将成为导致数据泄露的最常见攻击之一。

但是，是什么让 API 安全策略成为现代企业家的必备品呢？ 为什么对这项技术给予特别关注？ 将在本文中找到这些问题的答案以及如何降低 API 安全风险。

为什么要关心如何提高 API 安全性？

API 帮助企业实现真正的数字化。 无论您的应用程序是什么，应用程序编程接口 (API) 都会将其与其他软件或功能连接起来，从而节省从头开始构建它们的时间。

现在，API 之所以受到特别关注，是因为它们对企业成功的影响程度。

API 的商业利益

节省成本：由于 API 使企业能够利用其他公司的功能和数据，因此无需在内部创建这些功能。 在很大程度上有助于节省软件开发成本的活动。

更好的客户服务：通过链接多个软件，API 为企业提供了一个全面的客户视图和他们正在寻找的东西。 这些信息有助于公司更好地与消费者互动并做出明智的决定。

改善行业级协作：API 使企业能够与跨行业的其他公司建立联系，这些公司可以帮助使在线服务和平台变得健壮。 这反过来又改善了合作伙伴关系，创造了新的商业机会，并提高了企业运营的效率。

为商业智能收集数据：企业可以利用 API 来收集客户的偏好和行为。 然后对这些信息进行分析，以深入了解当前的市场趋势和客户需求。

创造新的收入模式：API 为企业提供了多个平台来推广和销售他们的服务、数字产品。 通过该模型，企业可以做任何事情，从向其他公司出售数据到基于现有 API 构建新软件。

API 在业务中的好处是多方面的。 但 API 安全风险也是如此。 黑客喜欢测试公司的 API 安全设计有两个主要原因。

为什么黑客喜欢 API

• 访问公司数据的一种简单方法——API 让黑客可以通过多个软件程序直接访问存储的数据，包括敏感信息。
• 绕过安全措施的一种简单模式——许多公司使用防火墙来保护他们的系统免受黑客攻击。 但是，少考虑 API 安全策略可以使黑客很容易通过这个后门进入软件。

因此，以下是导致 Web 应用程序 QA 团队特别关注的 API 的优缺点。

现在，我相信您一定想知道为什么 API 安全最佳实践列表与传统安全的列表不同。 在我们研究主要的 API 安全风险以及如何缓解它们之前，让我们先回答这个问题。

区别于传统安全的 API 安全设计的关键要素

传统的 Web 应用程序安全性和 Web API 安全性最佳实践存在巨大差异——这种差异源于它们的结构方式。

一座没有护城河和多个开口的城堡——早期，传统网络只需在 443 (HTTPS) 和 80 (HTTP) 等常用端口中进行保护。 如今，Web 应用程序带有多个使用不同协议的 API 端点，因此当 API 扩展其功能集时，管理其安全性变得困难。

频繁更改传入请求格式——API 在 DevOps 环境下不断发展，大多数 WAF 无法适应这种程度的弹性。 因此，每当 API 发生变化时，都必须手动重新配置和调整传统的安全措施——这种充满错误的方法会占用资源的时间。

客户端可能不使用 Web 浏览器——大多数微服务 API 用于移动应用程序或软件组件。 由于客户端不使用浏览器，网络安全工具无法使用浏览器验证功能并检测有害机器人。

API 结构的这种差异带来了几个 API 安全风险，认为对于 Web 应用程序开发人员和 QA 团队来说，实时找到解决方案并提高 API 安全性至关重要。

主要的 API 安全风险以及如何缓解它们

在我们开始讨论风险之前，让我告诉你 API 安全检查表是不确定的。 你认为你已经解决了所有的漏洞，新的漏洞就会出现。 解决这个问题的方法在于穿上黑客的鞋子，重新审视你的应用程序如何使用 API 以及被忽视的差距。

虽然这是一个长期、持续的解决方案，但一个好的起点是调查最常见的 API 安全风险。

1.不安全的分页

大多数 API 提供对资源的访问，这些资源是用户或小部件等实体的列表。 对于在浏览器上使用该软件的客户端，API 通常会过滤掉此列表并对其进行分页，以限制返回给客户端的项目数量。

但是，如果实体带有 PII 或其他一些信息，黑客将能够抓取端点并获取数据库中所有实体的列表。 如果实体意外暴露敏感信息，这可能非常危险。 它还将导致黑客能够查看您的网络应用程序的使用统计信息并访问电子邮件列表。

解决方案：为了防止分页攻击，应该能够跟踪单个资源在特定时间段内可以由用户或 API 密钥访问的项目数，而不是在请求级别。 通过测量单个用户级别的 API 资源访问，您将能够在 API 密钥或用户达到“一小时内触摸 10,000 个项目”之类的阈值后阻止他们。

2. 不安全的 API 密钥生成

大多数 API 通常通过 JWT（JSON Web 令牌）或 API 密钥进行保护。 这使您能够保护您的 API，因为安全工具能够识别异常行为，然后阻止对 API 密钥的访问。 但是，黑客仍然可以通过从用户那里获取和利用大量 API 密钥来超越这些方法，就像网络黑客如何利用 IP 地址来阻碍 DDoS 保护一样。

解决方案：保护这些攻击的可靠方法是需要人工注册服务，然后生成 API 密钥。 另一方面，可以使用 2-Factor Authentication 和 Captcha 等元素保存机器人流量。

3.意外按键曝光

API 密钥的使用方式使其容易遭受黑客攻击和泄漏。

• API 被设计为无限期获取，这增加了黑客获取未过期 API 密钥的机会。
• API 的用户可以直接访问 Web 应用程序的凭据，就像通过 CURL 或 Postman 调试它时一样。 在此之后，开发人员在 Stack Overflow 或 GitHub Issues 等公共论坛中复制/粘贴带有 API 密钥的 CURL 命令只是一个意外。
• API 密钥通常是不记名令牌，不需要任何识别信息。 API 无法利用 2 因素身份验证或一次性使用令牌等元素。

解决方案：保护密钥暴露的方法是使用两个令牌代替一个。 在这里，刷新令牌被存储为环境变量，可用于生成短期访问令牌。 与这些刷新令牌不同，开发人员可以使用可以访问资源的短期令牌，但只能在有限的时间段内使用。

4. DDoS 攻击

虽然 API 确实开启了新的商业模式，客户可以在其中以编程方式访问 API 平台，但这使得 DDoS 保护具有挑战性。 大多数 DDoS 保护都是为了在 DDoS 攻击期间吸收和拒绝来自不良行为者的请求而设计的。 对于 API 产品，这变得更加困难，因为每个流量最终看起来都像机器人流量。

解决方案：此上下文中的 API 安全最佳实践仅存在于 API 中。 对 Web 应用程序的每次访问都需要 API 密钥，因此当您遇到没有 API 密钥的请求时，您可以自动拒绝它。

5.错误的服务器安全

在维护良好的服务器卫生方面，API 与 Web 服务器没有太大区别。 由于 SSL 证书配置错误或通过非 HTTPS 流量，数据很容易泄露。

对于现代 Web 应用程序，虽然没有理由接受非 HTTPS 请求，但客户可能会意外地从其 Web 应用程序或 CURL 发出非 HTTP 请求，从而暴露 API 密钥。

解决方案： API 安全的最佳实践表明您应该通过 SSL 测试工具测试 SSL 实现。 此外，您应该通过负载均衡器阻止非 HTTP。

6. 记录不足

大多数全球泄露研究发现，识别数据泄露实例的时间段超过 200 天。 如果没有针对 API 日志记录定义的 API 安全最佳实践，黑客可以利用该漏洞制造更多漏洞。

解决方案：您应该确保您使用的 API 日志记录机制不仅可以跟踪 API 请求，还可以将其链接回用户进行行为分析并存储至少一年。 反过来，这些机制应该受到保护，以确保数据不会被删除。

7、不办理授权

虽然大多数 API 开发人员添加了全局身份验证方法（如 OAuth 或 API 密钥）来验证用户身份，但很难创建和保持授权与身份验证不同。

由于授权特定于应用程序的逻辑，因此开发人员在测试 Web 应用程序时会忽略它。 现在，除非对象标识符有足够的熵，否则黑客可以很容易地通过迭代测试不同的 id 并进入系统。

解决方案：确保您已通过身份验证的用户有权访问生成 API 响应所需的资源。 这可能包括根据与图片中的对象链接的访问控制列表 (ACL) 检查它。

以下是 Web 应用程序开发人员和企业家遇到的七种最常见的 API 安全风险及其解决方案。 但就像我们之前提到的，如果这个列表不明确，随着您的 Web 应用程序变老和 API 功能的扩展，可能会出现更多漏洞。

在 Appinventiv，当我们构建 API 时，我们会在开发过程开始之前为 API 安全测试制定一个粗略的清单。 除此之外，我们使用最好的 API 管理工具来确保您的软件具有长期的稳健性和安全性。

这是我们遵循的 API 安全清单。

Appinventiv API 安全最佳实践清单

作为一家 Web 应用程序开发公司，我们的不同之处在于我们遵循安全第一的开发方法。 这意味着，每次我们在其中构建或合并 API 时，我们都在您的应用程序的安全性之上。 我们的 QA 专家团队确保您的 Web 应用程序没有任何漏洞并且是防黑客攻击的。 他们确保这一点的一种方法是创建一个全面的 API 安全最佳实践清单。

1. 发现漏洞

提高 API 安全性的主要方法是识别 API 生命周期中的不安全区域。 有必要通过将 API 视为具有自己的开发阶段（如维护和功能到期）的软件工件来跟踪它。

2. 使用 OAuth

API 安全风险的最大差距之一是访问授权和身份验证控制。 OAuth 是一种强大的控制方法。 在 Appinventiv，我们使用令牌驱动的授权框架来允许第三方服务可以在不显示用户凭据的情况下访问哪些信息。

3.使用代币

一般来说，使用令牌是最好的 API 安全最佳实践之一。 开发人员可以利用分配给身份的令牌作为建立对受信任身份的受控访问的有效方式。

4.数据加密

提高 API 安全性的可靠方法是使用传输层安全性 (TLS) 加密数据。 当我们在 API 上工作时，我们遵循一种做法，即我们的开发人员还需要签名以确保仅通过授权用户修改和解密数据。

5. 使用率节流和限制

随着API 的流行度不断提高，像 DDoS 攻击这样的黑客攻击的可能性也在增加。 为了防止 DDoS 攻击和 API 峰值（如影响安全性和性能的问题），我们的开发人员对 API 的调用方式和频率设置了速率限制。 这种速率限制功能还可以限制连接，平衡数据访问和数据可用性。

6.使用API​​网关

使用 API 网关是我们认为的关键 API 安全最佳实践之一。 它充当 API 流量的执行点。 我们构建了一个网关，使企业能够验证流量、控制和监控 API 的使用方式。

7.使用服务网格

除了 API 网关，我们使用服务网格在 Web 应用程序中添加一层管理，因为服务网格将请求从一个服务路由到另一个服务。 它还优化了这些功能的协同工作方式，同时确保整合了适当的访问控制、身份验证和安全措施。

8. 零信任公式

在传统的安全模型中，使用的公式是简单的。 应该相信“内部”的东西，不应该相信“外部”的东西。 然而，网络现在变得复杂，因此拥有零信任模型 (ZTM) 变得很重要，尤其是在远程用户使用该软件的情况下。 通过 ZTM，安全重点从位置转移到资源和用户。

9. 验证参数

验证参数是我们 API 安全性的另一个最佳实践。 它有助于确保传入的数据不会造成任何伤害。 在该框架下，数据将根据报告允许输入系统的严格模式进行验证。

10. 建立威胁模型

我们减轻 API 安全风险的方法清单中的最后一个是威胁建模。 这是我们用于发现和评估风险的一种方法。 我们将其用作一种预防性方法，以受控方式评估、缓解和预防应用程序漏洞。

在这些 API 网关安全最佳实践的背后，我们能够构建一个强大、安全的系统，用户可以完全放心地使用它。 结果？ 我们拥有创建零黑客和安全漏洞实例的应用程序的记录。

离别笔记

随着企业继续将其单体系统转变为微服务，API 将继续容易出现漏洞。 这使得必须遵循本机和云 API 安全最佳实践。

我们上面提到的列表虽然是一个很好的起点，但需要不断升级。 对于企业家及其内部开发团队来说，保持领先地位可能是一项挑战，因为他们已经在多个截止日期之间进行了权衡。 这就是与一家拥有提供 100% 防黑客应用程序记录的公司合作的地方。 像 Appinventiv 这样的公司。

无论您的软件多么复杂，我们都可以通过我们广泛的质量保证服务使其安全可靠。 立即与我们联系，开启您产品安全的未来。