API NEWS | 谷歌推出新的 API 安全平台（附报告下载）

本周，我们带来的分享如下：

• 一份来自Imperva报告

• Google推出的新API安全平台

• API 驱动的后端以提高 API 安全性

• OWASP API安全前10名的综合初学者指南

上周，我们报道了 Imperva 与 Marsh McLennan 全球网络风险分析中心合作的最新报道，该报道表明，三分之一的事件源于不安全的 API。本周，我们将探讨 VentureBeat 提供的易受攻击的 API 对财务的影响。

随着 API 的使用在组织和行业中激增，正确保护 API 变得越来越紧迫。API 相关的攻击影响了几乎所有行业的公司，导致企业成本飙升。

为了量化 API 不安全的成本，Imperva 与 Marsh McLennan 网络风险分析中心合作分析与 API 相关的事件数据。他们的研究结果表明，缺乏安全的 API 可能会对您的业务产生负面影响，并强调了投资于全面的 API 安全解决方案的重要性。

• 仅在美国，每年与 API 相关的网络损失估计为 12-230 亿美元

• 受 API 相关事件影响最大的行业包括信息、专业服务、零售和金融

• 大型公司面临 API 相关事件的高风险

• 与 API 相关的美国网络年均损失— 12-230 亿美元

• 年均与 API 相关的全球网络总损失— 41-750 亿美元

• 年均与 API 相关的全球受保网络损失——2.05-3.76 亿美元

报告的第一个发现是 API 相关事件的发生率在 4.1% 到 7.5% 之间变化，其发生的可能性与组织的规模成正比：公司越大，发生 API 相关安全事件的机会就越大。

研究人员深入了解了 API 攻击的性质——从分布式拒绝服务 (DDoS) 攻击到泄露敏感数据的中间机 (MitM) 攻击、帐户接管和篡改 API 数据。不出所料，作者列举了 API 不安全的两个主要原因：API 的迅速扩散，以及对暴露的 API 和/或其安全状况缺乏可见性。

报告中另一个有趣的收获是在各个垂直行业中发生了与 API 相关的事件。在信息技术行业，高达 23% 的事件可以追溯到 API——这在很大程度上是因为 API 用于平台、服务和云基础设施的互连。专业服务排名第二，其次是制造、运输和公用事业。医疗保健行业报告的 API 相关事件发生率最低，为 1%，这可能是由于该行业软件开发的严格性和严格的合规性要求。

关注“星阑科技”公众号

后台回复“报告”可下载报告完整版

有消息称，关于 API 安全工具和解决方案的话题，谷歌宣布了一款名为 Advanced API Security 的新产品，该产品目前处于预览模式。该产品建立在其广受欢迎的 Apigee API 网关之上，并专注于两个关键的 API 安全领域：识别 API 代理错误配置和防止基于机器人的攻击。新产品专门针对谷歌的金融服务客户——目前，五分之四的美国银行使用 Apigee。

在OWASP API安全十大漏洞中，API7:2019 — 安全错误配置可能是最容易防止使用API服务器和网关自动检查来识别常见安全错误配置的漏洞之一。这是高级API安全产品的另一个重点领域，尽管现阶段公布的细节很少，但该产品将可能通过扫描 API 和流量以识别信息泄露或泄漏，通常是 PII 或医疗保健数据。

根据第一篇文章，许多基于 API 的攻击是可以使用适当的安全工具来预防的——谷歌的这一产品将改善用户的 API 安全状况。

一篇来自 Curity 的 Gary Archer 的优秀技术文章，主题是 API-driven backends for frontends 以提高 API 安全性。本文对如何基于单页应用程序 (SPA) 模型保护现代 Web 应用程序进行了讨论。通常，它们包括两个后端——第一个是内容交付网络 (CDN)，提供静态或服务器渲染的内容，第二个是 API 后端，负责根据用户操作提供动态页面内容。

本文描述了基于 OAuth2 和 OpenID 模式提供 API 安全性的强大且可扩展的方法。在下面的第一张图中，API 后端分为两个组件——所谓的后端换前端负责处理初始身份验证并返回可以嵌入标准 Web cookie 中的不透明令牌。然后，SPA 可以通过呈现 Web cookie 向 API 发出后续请求，该 Web cookie 被交换为 JWT，以由 API 后端验证。

Curity 描述了他们的API-driven Backend for Frontend模式，以促进基于标准组件的可扩展且紧凑的解决方案。如下所示，OAuth 代理处理初始身份验证，在后续请求中，OAuth 代理负责将 Web cookie 交换为呈现给 API 后端的 JWT。

本周我们对 OWASP API 安全前 10 名的知识体系做出了另一项贡献，这次来自 Tyk 的团队。

Tyk 提供了对前 10 名的不同的看法，专注于 OWASP 风险评级方法来对前 10 名漏洞进行评级和排名。该方法根据不同的标准评估风险；威胁代理、可利用性、弱点普遍性、弱点可检测性、技术影响和业务影响。这种有趣的方法使安全团队能够了解漏洞的相对优先级，以便进行有针对性的补救。

• OWASP 强调的威胁性质广泛，需要同样广泛的解决方案来缓解这些威胁。

• API 管理是缓解 API 威胁的关键组件。

• 没有可以抵御所有攻击媒介的交钥匙解决方案。威胁防护需要全栈工作，包括 API 请求/响应路径中涉及的许多组件。

• 威胁严重性是概括性的。现实情况是，每个 API 都有不同程度的易感性，这取决于许多内在因素。

• API 安全必须是一个持续的过程。随着 API 的发展，为保护它而采取的安全措施也必须如此。

• 了解 API 管理可以帮助和不能帮助的内容，并相应地使用它。APIM 提供了许多工具。必须小心选择、配置和验证要在 API 上下文中使用的内容。

• 选择缓解问题的正确级别。为了尽量减少其影响，最好在网络边缘解决拒绝服务攻击，最好是在 API 基础设施之外。而对象级授权则相反，这最好由 API 本身解决。

• 验证实施的保护措施不会以其他方式加剧问题。例如，通过重试失败的请求并在 API 上产生额外的负载。

• 教育 API 产品团队，让他们了解 API 面临的威胁以及如何缓解这些威胁。使安全成为整个 API 开发过程中的关键问题。

• 结合自动化和手动测试策略来验证功能性和非功能性安全需求。自动化流程速度很快，并且可以集成到开发生命周期中，从而在流程的早期突出显示问题。手动过程较慢，但它们的探索性使他们能够找到边缘情况。

OWASP 根据许多不同的标准评估风险；威胁代理、可利用性、弱点普遍性、弱点可检测性、技术影响和业务影响。

在 API 安全的情况下，威胁代理和业务影响始终分别是API 特定和业务特定的。其余标准的分数从 1 到 3，分数越高代表风险越高：

感谢 APIsecurity.io 提供相关内容