技术博客

API安全不仅仅是限制策略

2022-05-12阅读:38

API 管理承诺使用众所周知的简单技术公开和保护数据的涅槃。供应商专注于创建 API 的难易程度,并且几乎总是将安全性作为其 API 生命周期故事的一部分。

然而,我们都看到了头条新闻尖叫最新的安全漏洞。那么,在 API 管理方面,”安全性”的真正含义是什么呢?

API管理安全术语

大多数API管理解决方案供应商从OAuth、密钥管理和TLS的角度讨论安全性。这些都适用于整体安全问题。大多数供应商还将具有易于使用的策略,这些策略可根据客户端使用情况限制请求。这些限制策略采取的形式是阻止单个客户端在一段时间内访问特定API(例如,允许它们每分钟调用 20 次)。


上图显示了这些”基础”安全元素。这些要点是大多数 API 管理解决方案供应商所强调的,有些供应商除此之外没有任何其他安全策略。但有效的 API 管理需要的远不止于此。


限制是不够的

如果我们回到SOA和XML攻击的”好日子”,就会发现像SQL注入(恶意SQL语句的执行)和XML攻击”炸弹”(大量的XML标签数组)这样的攻击。


API管理在这方面几乎没有什么不同:仍然会有依赖于简单API的攻击,这些API只是从实现的角度而不是从安全的角度来看待的。


考虑API允许检索一系列值的情况;假设 min=n 和 max=p。在这种情况下,我们可以看到,具有非常高的”max”数字的请求可能会使后端系统过载。


另一个简单的攻击是有效负载可能包含字符串的地方。除非制定策略来确保字符串保持在特定参数范围内,否则后端可能会再次克服(范围攻击)。


用更专业的术语来说,我们可以看到:


分布式攻击:分布式拒绝服务攻击(DDOS)是一个很好的例子,说明简单的限制策略根本行不通。在这些攻击中,多个 IP 地址和多个不同的客户端会尝试泛滥 API。限制策略通常适用于单个 IP 地址或单个客户端密钥。如果从多个客户端地址或使用多个客户端密钥,则看到攻击正在发生,这是一个复杂得多的问题。


微服务攻击:微服务架构也让我们发现了一个新问题:如果许多前端解决方案使用相同的后端服务,那么攻击者可能会调用完全不同的前端API,但它们都可能汇集到一个或两个后端系统,从而压倒它。


尽管从攻击者的角度来看,很难确定哪些服务容易受到攻击 - 但从提供商的角度来看,鉴于关系的复杂性,确定攻击是否正在进行中同样困难。


网络攻击:许多攻击仍然基于旧问题。诸如慢速发布(应用程序通过缓慢发送数据来保持打开的连接)或登录攻击(不断尝试登录)等概念。这些是众所周知的问题,应使用众所周知的解决方案进行处理。



上图显示了供应商通常不会深入讨论的攻击层。


攻击缓解

我希望我已经证明,API 管理安全性的问题是一个需要更深入地考虑的问题,而不仅仅是 API 是否具有适当的限制策略。基本的网络攻击、”老式”的HTTP攻击、内容攻击和多级DDOS攻击都在发挥作用。


鉴于这种复杂性,很明显,一种技术和策略无法解决问题。所有通常的网络和 HTTP 防火墙以及较新的限制策略都必须到位。但是,API管理还需要良好的安全测试才能到位 - 我怀疑我们都因为没有考虑将我们想要花钱作为主要位置而感到内疚!我们需要检查我们的API是否没有SQL注入的潜力,并且我们是否已经进行了范围检查之类的事情。


一旦这些制衡措施到位,就必须积极管理API。需要验证流量异常,以便可以检查峰值是否是良好用例的结果,而不是坏用例的结果。必须一直启用监视直到后端服务,以确保分布式攻击不会利用较新体系结构的复杂性。


此外,现在有许多公司可以帮助DDOS缓解,例如Cloudflare或亚马逊的”Shield”服务。这些消除了大部分负担,使你可以专注于自己的业务。


结论


API管理时代的安全性与SOA一样复杂,远远超出了附加到面向外部的API的简单限制策略。

需要了解大量面向外部的API与后端系统的交互,以满足分布式攻击的需求。主动API管理将有助于查找发生异常的位置,并且可能需要修复。这些方法与良好的HTTP和网络防火墙相结合,应该可以阻止大多数攻击,或者至少在它们到达时遏制它们。


DDOS攻击可以通过自己的安全性或在一些正在涌现的新外部服务的帮助下来缓解。

切勿吝啬对API内容逻辑的良好前期测试。API管理侧重于快速公开数据的能力,但这种速度带来了与我们一如既往的安全问题。确保API在设计和测试时具有从你使用的任何其他系统获得的所有严格要求,并围绕它们创建良好的安全测试和监视解决方案。


参考:John Hawkins

下载中心

姓名

电话

邮箱

职位

所属行业

所在公司

提交成功