数字转型是基于一种可驱动新的操作模型的 API，提供对业务逻辑、应用程序和数据的直接访问。虽然这种访问对于员工，合作伙伴和客户来说非常方便，但它也使 API 成为黑客和恶意网络的攻击目标。随着越来越多的攻击和漏洞，扩展安全性现在变得越来越重要。

现有的解决方案（例如访问控制，速率限制等）提供基本保护，但不足以完全阻止恶意攻击。今天的安全团队需要识别并响应动态变化的攻击，这些攻击利用了各个 API 的自我漏洞而提高了攻击的成功率。想想在未来，人工智能可以检测 API 以及其他泄露数据的异常行为，自动阻止对整个 API 基础架构的攻击，并设计完善解决方案是多么值得期待的事。此方法为 IT 基础架构提供了深入的可见性，并使安全团队能够在识别出恶意行为时立即采取行动。

API 违规

2019 年，澳大利亚最大的房地产估价公司 LandMark White 发生 API 漏洞，导致房产估价细节和客户信息泄露。在这种情况下，本来只供内部使用的 API 却可以从公司域外访问。

这些漏洞导致了不同程度的公司违规行为，包括账户被接管，私人信息和照片被盗以及信用卡号码的提取。在此次违规行为之后，该公司的良好声誉遭到破坏，他们的客户和银行合作伙伴急忙寻找其他替代品。

从泄露到发现漏洞整个过程持续了数周或数月才被检测到，同时其他类似的违规行为已经花了将近一年时间才能完全解决。除 LandMark White 外，到目前为止许多人信息仍是没有保障的，这是一件十分危险的事情。要了解如何防范这些威胁，我们必须首先了解 API 所带来的潜在漏洞。

API 漏洞

许多企业目前依靠不充分的安全措施来保护其 API。虽然 API 管理工具提供了一些重要的安全功能，包括身份验证和速率限制，但这些做法通常无法阻止专门为违反 API 及其提供访问权限的数据和系统而构建的攻击。

1. 不完整的验证

缺少权限审查是最近一系列 API 违规中反复出现的漏洞模式。这些丢失的权限审查会在生产 API 中暴露漏洞。在某些情况下，完全缺乏访问控制已经使 API 信息暴露，使得具有基本技能的不良行为者可以进行恶意攻击。

在 Facebook，USPS 和 Verizon / LocationSmart 的情况下，黑客使用特定帐户对 API 行为进行反向工程，以识别至少一个漏洞，该漏洞可以在没有正确凭证检查的情况下提供对来自其他帐户的数据的访问，而且将所有这些都伪装成像普通用户。这种技术有可能提供对大量账户的访问，并已成功用于破坏某些银行和保险公司。

如果调用 API 的应用程序时，可能不会暴露上述漏洞。因为通过跳过客户端应用程序（例如，Web 应用程序）并直接调用 API 来观察数据和控制流，是会获得恶意访问的。客户端应用程序极大地限制了通过用户界面限制使用 API​​的方式，依赖应用程序可能会提高些许安全性，尤其是在 API 层的应用程序之外未执行测试时。

除了访问控制之外，API 安全性还必须包括内容验证。在 2019 年初发现（已经修复）的 Kubernetes 的 API 服务器事件，向我们展示了这种缺乏安全性内容是致命的。整个事件起始是被授权向 Kubernetes API 服务器发出补丁请求的用户可以发送过量消耗的特别补丁。这种处理过程中的资源上传，导致 API 服务器上遭受到服务（DoS）攻击。

利用此类漏洞可以极大地破坏服务，如果传入的 JSON 补丁包含超过 10,000 个操作，则 Kubernetes API 服务器修复包括返回 413 类型错误。这种类型的内容验证很容易在 API 网关中配置，但它经常被遗漏，因为这样做需要超越自动生成的 JSON 模式，这些模式只定义简单的规则类型，需要人工干预才能识别特定验证的需要，并确保正确的配置和测试。

2.API 缺乏可见性

就目前来看，API 数量的激增只会增加其漏洞。API 的部署速度比以往任何时候都要快，而且很多不同的团队在某些情况下，要求创新、减少摩擦和创造新收入流的持续压力会导致 API 不可用的意外影响。

因此，许多利益相关者报告其组织部署的所有 API 缺乏可见性，这并不奇怪。事实上，许多 API 相关的漏洞已经被发现几个月，甚至是几年，这进一步说明了整体 API 设计缺乏可见性。

此外，一些 API 并不是公开的，可能只被视为总体项目的实施细节。这使他们会被从安全性的角度隐藏起来，但反过来又导致缺乏特定的安全考虑因素。在其他情况下，从组织的不同部分出现的 API 可会因为异构平台导致不一致的安全策略。

无论如何，这些 API 可能与公共 API 一样容易受到攻击，因为它们同样容易被黑客反向设计。为弥补这些差距，我们需要清楚地了解需要保护的内容，对 API 流量的深入洞察为改善网络安全提供了起点。

3. 超越 Token 验证的思考

验证 Token 并验证请求用户的身份通常不足以支持 API 基础结构。在 API 层应用粒度访问控制的能力不仅符合逻辑，而且随着 API 成为访问开发人员的数据的最常用渠道，它将成为常态。

此外，定义应允许个人请求哪些数据的规则不仅由 API 提供商定义，还由用户定义。这些决策允许用户在涉及他们拥有的数据时限制应用程序，因此用户 API 的管理策略与核心 API 安全性概念紧密相关。

API 基础安全的核心是审查和治理流程的定义，更新的 API 必须经过审核，首先要确定问题的答案，包括：

• 访问 API 需要哪些权限？
• 谁是预期的请求者？
• 该服务将利用哪些数据库和数据进行读写？
• 该 API 与之交互的其他服务是什么？
• 输入和输出参数是什么样的，它们应该如何被限制？

这些问题的答案会告诉我们预备发布的新 API 应该采取哪些安全策略。

4. 扩展旧的基础 API 安全性

即使有正确的基础，安全性也只能保持与其配置的程度相当而已。当配置受到人为错误的影响时，API 漏洞使其经过测试并投入生产的风险随着 API 层复杂性的增加而增加。即使你已采取一切措施来防止它，仍然可能面临在 API 本身上暴露漏洞的风险。

例如，黑客经常通过网络钓鱼攻击窃取 tokens，这些攻击允许他们构成合法的应用程序。此外，代表用户调用 API 的客户端应用程序也存在缺陷，并且在保密方面非常糟糕。这可以像通过查看应用程序的 JavaScript 代码或通过 HTTPS 代理查看 API 流量而进行反向破解 API 密钥一样简单。

例如，北卡罗来纳州立大学的一项研究表明，GitHub 是一个用于调用 API 的应用程序机密宝库，超过 100,000 个存储库泄漏了 API token 和加密密钥。GitHub 通过实施新的安全功能从提交到其平台的代码中扫描 token 来实现这一发现。

攻击者还使用远程访问特洛伊木马来窃​​取凭据，如 Mimikatz。然后，他们使用窃取的凭据来冒充用户并获取 token。另一个常见漏洞是授权服务器上的凭据填充，利用从先前漏洞中挖掘的凭证集合。

在每种情况下，攻击者都会利用用户调用客户端应用程序或授权服务器上的漏洞获取 token，而不是 API 本身。这提出了许多问题，因为这些 token 似乎是合法的，黑客看起来像一个有效的用户。这为用户数据“通过 API 泄漏”设置了台阶，即使有适当的访问控制策略和运行时实施，这些攻击除了那些涉及 API 本身漏洞的攻击，也不会被传统的 API 安全工具检测到，而且通常持续数月甚至数年。

安全团队可以投入大量精力教育用户和 API 开发人员关于客户端应用程序安全性和身份基础架构，但他们仍然可能面临生产 API 漏洞和凭据泄露的风险。API 提供商必须在其安全措施中考虑这一点，无论 API 是内部还是外部。但其实可以通过应用人工智能（AI）来加速攻击检测和自动阻止攻击。

将 AI 应用于安全性

安全团队可以根据用户通常展示的 API 行为来培训机器学习引擎。通过使用 AI，团队可以识别好的和坏的流量，并在没有人工干预的情况下识别未遂的攻击和持续的攻击。

1. 用 AI 检测非典型行为

每个 API 调用时，访问 token 或 cookie 的数据以及某些操作的时间和顺序都可以提供给 AI 模型。在运行时，此机器学习引擎利用行为模型来识别潜在威胁的迹象，例如特定 token 或 cookie 是否在合法应用程序之外使用，数据是否被泄露或更改等。

利用基于 AI 的异常使用检测可显着加速威胁可见性，将攻击发现从数月转换为数分钟或数秒。检测到可疑 API 活动后，用于获取 API 访问权限的访问 token 或 Cookie 可以列入黑名单或撤销，立即停止在所有 API 端点上使用该 token 从任何一方进行访问。如果这些攻击背后存在相同的用户身份，则必须将用户身份本身列入黑名单并相应地进行标记。在没有人为干预的情况下实现这种类型的监视，攻击检测和阻止。

2. 使用 API​​诱饵

API 陷阱的使用也可以加速 API 黑客攻击的检测。这涉及添加伪造的 API 资源，这些资源会向请求者返回看似有效的响应。陷阱利用黑客倾向于以合法应用程序不具备的方式进行搜索，有效地转变为桌面以利用围绕典型黑客行为的知识。

当黑客陷入这些陷阱时，他们会立即得到认可。同时，他们的相关 IP 地址和访问 token（如果他们当时拥有它们）会自动被视为已泄露并列入黑名单。陷阱侦听器能够识别出这些请求不可能从真正的应用程序传入，因为这些 API 资源不合法存在。这些安全措施不需要自定义规则或扩展配置。

3. 阻止和修复

当然，检测只是解决方案的一部分，系统如何反馈同样重要。一旦发现客户私人信息（例如 token）已被泄露，该信息必须立即被撤销或列入黑名单。此外，必须记录这些事件以供后续审核，并且必须通知安全信息和事件管理（SIEM）系统以应对接下来类似的情况。

应记录有关在检测和阻止受损凭据之前调用的方法和资源的详细信息，以报告形式提供的信息允许 API 提供者、DevOps 团队或安全团队采取必要措施来修复或逆转攻击造成的损害。

保护 API 的技术和工具

使用合适的技术和工具来保障 API 的安全性，是一种最易实现的举措。现在，有许多技术和工具可以最大程度上的保护 API 免受网络攻击和黑客入侵，最简单的就是用 API gateway（API 网关），通过流量过滤和节点监控等方式去防止未知的攻击和入侵。诸如国外的 Amazon API Gateway（亚马逊旗下）、国内的 GOKU API Gateway（EOLINKER 旗下）等都能轻松的实现网关系统的要求。在 API gateway 这个领域，也有一些开源框架在活跃，如 Netflix Zuul，基于 Nginx 的 Kong 等，目前关注较少，就不展开介绍了。在选择网关系统时，安全性、便捷性和本土化性需要特别关注的几个关键因素，这些网关都对 API 的安全性有一定的保障，使得私密的信息能免遭泄露。

结论

API 安全性是数字化转型计划的重要组成部分，可以提高跨渠道的网络安全。在危机四伏的时代，采用以身份为中心的 API 安全基础设施是现代数字化转型战略的核心。为了确保 API 的安全性，还需要深入了解 API 活动和 AI 驱动的漏洞检测。两者都需要在基本的 API 访问控制上进行分层，以捕获源自 API 漏洞的攻击，并在传统 API 安全系统的配置中修复人为错误的风险。

参考资料：Jinesh Thakkar，Secure APIs Using Artificial Intelligence

原文链接：https://dzone.com/articles/se…

图片来源：互联网