程序员征服安全：OWASP API 十大风险系列 - 资产管理不当

与 OWASP API 十大风险中的大多数漏洞不同，资产管理不当并非主要源于代码缺陷。相反，这种漏洞更多是人为或管理层面的问题，导致旧版 API 在本应被更安全的新版本取代后，仍长期处于运行状态。此外，如果处于开发阶段的 API 在未完全加固以抵御威胁的情况下就被暴露在生产环境中，也会引发此问题。

随着微服务和云计算的兴起，此类漏洞变得尤为难以管理。在这种环境下，新服务可能会为了满足临时需求而迅速启动，随后却被遗忘且从未被停用。如果这些旧版 API 仍与生产环境保持连接，可能会危及整个网络的安全。

想尝试针对此安全漏洞的游戏化挑战吗？进入我们的竞技场： [立即开始]

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

资产管理不当是现代环境下的产物。企业为了追求业务速度，有时每天会启动成百上千个服务和微服务。这一过程往往非常迅速，且缺乏相应的文档记录，也没有说明相关 API 的用途、预计使用时长或其重要性。这会迅速导致 API 激增，随着时间推移可能变得难以控制，尤其是当缺乏明确的 API 生命周期管理政策时。

在这种环境下，某些 API 极有可能被遗忘、丢失或从未被停用。

有时，拥有在常规流程之外创建新服务权限的用户也难辞其咎。例如，营销团队可能会为了支持产品发布等活动而创建一个服务，但在活动结束后却从未将其下线。后来的人在查看该服务及其关联的 API 时，可能完全不了解其存在原因；如果缺乏文档，这就会成为一个谜。由于不清楚这些 API 的重要性或具体功能，他们可能不敢将其从生产环境中移除，甚至不敢将其升级到新版本。

这种漏洞之所以危险，是因为框架中 API 的安全性会随时间推移而提升。研究人员可能会发现漏洞，或者通过增加额外的安全措施来抵御日益流行的攻击类型。如果旧版 API 未经升级，它们仍可能遭受此类攻击，因此黑客经常会利用自动化工具搜寻这些遗留的 API。

在 OWASP 提供的一个真实案例中，某公司升级了用于搜索用户数据库的 API 以修复一个严重缺陷，但却错误地保留了旧版 API。

攻击者注意到新 API 的位置类似于 (api.criticalservice.com/v2)。通过将 URL 替换为 (api.criticalservice.com/v1)，他们成功调用了存在已知漏洞的旧版 API。这最终导致超过 1 亿用户的个人记录被泄露。

消除资产管理不当的缺陷

消除环境中资产管理不当缺陷的唯一方法是，对所有 API 及其用途和版本进行严格的清单管理。这应从现有 API 的盘点开始，重点关注其部署环境（如生产环境或开发环境）、应具备网络访问权限的人员，当然还有版本信息。

完成盘点后，您需要实施一套流程，确保为所有新创建的 API 或服务自动添加文档。文档应涵盖 API 的各个方面，包括速率限制、请求与响应处理方式、资源共享、可连接的端点、相关适用政策，以及后续审计所需的任何其他信息。此外，应避免在生产环境中使用非生产环境或开发环境的 API。考虑为 API 设置有效期，要求所有者证明其持续使用的必要性，以防止自动停用失效。

每当活跃 API 有新版本发布时，请进行风险评估，以确定是否应进行升级，以及如何执行升级以避免干扰生产环境。迁移到新 API 后，请务必将旧版本从环境中彻底移除。

采取上述措施有助于防止资产管理不当漏洞损害您的组织、用户或网络。请查看 Secure Code Warrior 博客页面，深入了解此漏洞以及如何保护您的组织和客户免受其他安全缺陷的侵害。您还可以 申请演示 Secure Code Warrior 培训平台，以保持您的网络安全技能精进且与时俱进。

‍