与OWASP API前十名中的大多数漏洞不同，不恰当的资产管理并不特别围绕编码缺陷。相反，这个漏洞更像是一个人为或管理问题，它允许旧的API在应该被较新的、更安全的版本取代后很久还在原地。如果仍在开发中的API在被完全加固以抵御威胁之前就暴露在生产环境中，也会发生这种情况。

由于微服务和云计算的出现，这一漏洞尤其难以管理。在这种环境下，新的服务可能会被迅速启动，以满足暂时的需要，然后被遗忘，从未退役。如果旧的API被留在生产环境中连接，它可能会危及整个网络。

想尝试一下对这个安全漏洞的游戏化挑战吗？请进入我们的竞技场。[从这里开始]

不当的资产管理缺陷是如何影响API的？

不当的资产管理缺陷是现代的产物。以业务速度前进的组织有时每天都能旋转出成百上千的服务和微服务。这通常是快速完成的，而且没有创建任何附带的文档，也没有解释相关的API是用来做什么的，需要多长时间或其重要性。这可能会迅速产生API蔓延，随着时间的推移可能会变得无法控制，特别是如果没有全面的政策来定义API可以存在多久。

在这种环境下，很有可能一些API会丢失、被遗忘或从未退役。

有权限在正常流程之外创建新服务的用户有时也应受到指责。例如，一个营销小组可能会创建一个服务来帮助支持一个即将到来的事件，如产品发布，然后在事件完成后再也没有把它拿下来。后来有人看到这个服务及其相关的API，可能不知道它们为什么会存在，如果没有文档，它可能仍然是个谜。他们可能不愿意从生产环境中删除这些API，甚至不愿意将它们升级到新的版本，因为他们不知道这些API有多关键，也不知道它们是做什么的。

漏洞变得很危险，因为框架中的API的安全性随着时间的推移而提高。研究人员可能会发现一个漏洞，或者可以增加额外的安全性来阻止越来越流行的攻击类型。除非升级，否则较旧的API可能仍然容易受到这些攻击，所以黑客通常会搜索它们或使用自动工具来寻找它们。

在OWASP提供的一个真实案例中，一家公司升级了其用于搜索用户数据库的API，以修补一个关键的缺陷。但他们错误地将旧的API留在了原地。

攻击者注意到，新API的位置类似于（api.criticalservice.com/v2）。通过用(api.criticalservice.com/v1)替换这个URL，他们就能够使用带有已知漏洞的旧API。这最终暴露了超过1亿用户的个人记录。

消除不当的资产管理缺陷

从你的环境中消除不恰当的资产管理缺陷的唯一方法是对所有的API、它们的用途和版本进行严格的盘点。这应该从现有的API清单开始，关注的因素包括它们应该被部署到什么环境中，如生产或开发，谁应该对它们有网络访问权，当然还有它们的版本。

一旦完成，你需要实施一个流程，将文档自动添加到任何新创建的API或服务中。这应该包括API的所有方面，包括速率限制、如何处理请求和响应、资源共享、可以连接到哪些端点、任何适用的相关政策，以及其他任何以后需要审计的内容。你也应该避免在生产中使用非生产的API或来自开发环境的API。也可以考虑给API增加一个时间限制，在这个时间限制内，API的继续使用必须有其所有者的证明，以防止自动退役。

每当活动API的新版本可用时，执行风险assessment ，以确定你是否应该升级，以及该过程应如何进行，以避免破坏生产环境。一旦你迁移到新的API，从环境中完全删除旧的API。

做好这一切可以帮助防止不当的资产管理漏洞对你的组织、用户或网络造成伤害。请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。

‍