防御API安全风险：CISO指南

Web 应用程序安全并非新鲜事。自 20 世纪 90 年代万维网诞生以来，我们已经看到了 Web 漏洞及其对企业的影响。当今的 Web 应用程序环境非常复杂。从底层 Web 服务器到相关的应用程序和数据库服务器，有许多活动部件。这些部件不仅必须从一开始就正确配置和部署，还必须得到良好的维护和管理，以便能够检测到安全攻击，最好是从一开始就防止安全攻击。所有这些复杂性可能会分散内部技术人员和外包供应商的注意力，最终导致对您最关键的业务应用程序的安全漏洞被利用。作为 CISO，您不希望这种情况发生在您的任期内。这只是传统 Web 方面的事情。

Web 应用程序生态系统中有一个部分尚未得到太多关注，但同样需要关注，那就是应用程序编程接口 (API) 安全性。在现代动态应用程序领域，API 是重中之重。事实上，根据 CloudFlare 的数据，API 调用占所有 Web 流量的一半以上。这些 API 也是恶意行为者的目标，他们正在寻找通过 API 本身直接利用传统 Web 漏洞的方法。Web API 提供应用程序到应用程序的交互，其功能集可实现进一步的可扩展性和与最终用户、客户和业务合作伙伴的连接。JavaScript 及其各种迭代等现代 Web 应用程序语言在云端比以往更多地利用 API。这对企业和犯罪黑客来说都是好事。

您不想错过的 API 安全漏洞

与整个 Web 应用程序环境相比，Web API 端点占用的空间相对较小。但它们为应用程序的关键部分提供了切入点，攻击者可以利用这些切入点进行交互和操纵，以获取不义之财。一些 API 漏洞可以促进对用户的攻击。其他漏洞则可能导致 Web 环境完全被攻陷。

人们经常忽视的一个现实是，API 往往容易受到过去 30 年来困扰 Web 应用程序的相同 Web 缺陷的影响，例如：

• 身份验证操纵——包括允许绕过凭证的攻击
• 用户会话操纵——包括捕获和重新连接预定渠道之外的会话
• 未经授权的访问——包括特权升级攻击，允许某人执行超出预期的操作
• SQL 注入——包括能够与数据库交互，甚至获取远程命令提示符
• 安全配置错误——包括针对默认 Web 服务器配置和 TLS 的攻击
• 拒绝服务 (DoS) 攻击 – 包括使应用程序或整个服务器脱机

上述许多漏洞都可能被外部黑客或恶意内部用户利用，并且很可能逃过任何安全警报的侦查。渎职行为的证据可能要等到启动组织的事件响应计划时才会出现，甚至永远不会出现。

有助于最大限度降低风险的关键 API 安全工具

在 API 安全漏洞的乌云中，也有一线希望。事实上，企业并非束手无策。与标准 Web 应用程序一样，当攻击者试图利用这些漏洞时，可以采取很多措施来预防或至少将影响降至最低。作为 CISO，组织内外的其他人都希望您采取适当的措施来确保一切顺利。

有助于发现漏洞并最大限度地减少整个企业的 API 攻击面的解决方案包括：

• 传统的渗透测试工具——Web 代理和各种浏览器插件是发现与身份验证、会话操纵和未经授权的访问相关的漏洞的绝佳工具。
• API 安全测试工具——静态应用程序安全测试（SAST）、动态应用程序安全测试（DAST）和交互式应用程序安全测试（IAST），诸如 Web 漏洞扫描程序之类的工具，特别是那些具有专门 API 测试功能的工具，通常可以比单独的手动测试发现更多更好的 API 相关漏洞。
• API 安全网关——客户端端点和后端 API 服务之间的中介，也可以监控和记录 API 交易并对潜在威胁发出警报。
• Web 应用程序防火墙 (WAF) – 在应用程序层（OSI 模型的第 7 层）工作的控制，查找并阻止特定应用程序和 API 漏洞。
• 开发人员培训和将测试进一步转移到软件开发生命周期的左侧——让负责构建安全代码的人员得到更好的教育并尽早参与到这一过程。

重要的是进行适当且持续的网络安全评估，以便确认这些挑战，即使不能完全解决，至少也能部分缓解。您无法保护您不承认的东西，因此充分了解应用程序和 API 环境的风险级别是关键。

推进 API 安全

在安全测试和监督方面，API 经常被忽视。这种疏忽有时发生在漏洞和渗透测试的范围界定阶段。进行测试的一方或系统所有者根本没有考虑已发布的 API 是否存在。一些开发和安全团队未能将 Web API 纳入其安全标准的同一保护范围。另一种情况是，执行了 Web API 安全测试，但没有使用正确的工具从所有适当的角度对其进行正确测试。不过，其他时候，人们认为可以完全跳过 Web API，因为它们的可见性不高或在攻击面或价值方面没有提供太多帮助。最糟糕的情况是，当 API 没有作为组织整体安全计划的一部分得到充分监控时。当漏洞发生时，没有人知道。这些都是危险的方法，显然会导致不良事件。

所有这些疏忽都可能造成一种错觉，即网络环境是安全的。工作已经完成。钱已经花掉。复选框已经选中。然而，仍然没有对系统的每个部分进行评估和监控，以发现当时或持续存在的安全漏洞。这就像医生可能不会为生病的病人安排适当的血液检查或放射学检查。某些工作已经完成，病人得到了健康证明，但由于简单的疏忽，未知的病症或疾病仍然潜伏着。痛苦仍在继续。

随着 API 在整个企业中越来越普及，将它们纳入持续的安全讨论中非常重要。有太多事情可能发生，而且损失实在太大。主动威胁建模和安全标准应该像适用于其他 Web 应用程序组件一样适用于 API。诸如OWASP API 安全项目之类的标准应该集成到您的开发生命周期中。主动安全测试和系统监控与警报也是如此 – 贯穿整个应用程序的生命周期。如果存在 API，则需要将其纳入监督和审查范围。其他任何事情可能都不够，可能只会助长您迄今为止投入了大量时间、金钱和精力来防止的漏洞。作为您组织的安全负责人，请立即按照您的条件采取行动，以免被迫按照他人的条件采取行动。

Kevin Beaver，CISSP 是总部位于佐治亚州亚特兰大的 Principle Logic, LLC的独立信息安全顾问、作家和专业演讲者。Kevin 拥有超过 34 年的 IT 经验和 28 年的安全经验，擅长漏洞和渗透测试、安全计划审查和虚拟 CISO 咨询工作，帮助企业消除造成虚假安全感的障碍。他撰写了 12 本安全书籍，包括畅销书 《黑客入门》 （目前为第 7 版）和 《HIPAA 隐私和安全合规实用指南》 （目前为第 2 版）。Kevin 撰写了 1,300 多篇安全文章，并定期为包括 SearchSecurity.com 在内的各种 TechTarget 网站撰稿。他拥有南方技术学院计算机工程技术学士学位和佐治亚理工学院技术管理硕士学位。

文章来源：Defending Against API Security Risks: A CISO’s Guide