API安全测试：是否存在无限制的资源消耗

在这个博客系列文章中，我将探讨OWASP API安全十大漏洞。对于每一个漏洞，我都会向你展示如何在API上进行实验来测试其是否存在，并分享我的观察结果。

在这些博客文章中，我将使用不同的API作为测试对象。所有使用的API都是演示API，即它们并未在现实生活或公共应用程序中使用。因此，除非故意设置，否则我们在这些API中发现的任何漏洞都是无害的。

以下是目录：

如果一个API或端点不对向其发出的客户端请求数量或通过其暴露的资源的访问设置任何限制，那么这个API就被认为存在无限制资源消耗的问题。

受到无限制资源消耗的影响可能会导致多种问题，包括拒绝服务攻击（DDos）和使用付费第三方服务的成本飙升，以及一些怀有恶意的人轻松搜索并从你的API端点抓取数据。

举个例子，回顾一下我们在本系列的前一篇文章中测试对象级别授权漏洞（Broken Object Level Authorization）的例子。在那里，我们扫描了10000到20000之间的所有账户号码，以查看我们是否能够访问到本不应查看的数据（剧透：我们成功了）。

之所以能够如此轻松地完成这一操作，并且说实话，简直是易如反掌，就是因为API端点允许我们快速连续地发出这10000次请求，这可以通过脚本甚至像Postman这样的工具和自定义数据源轻松实现。

如果接口/端点实施了某种速率限制，以限制在特定时间段内可以从某个端点发出的请求数量，那么以这种方式查找我们本不应访问的数据就会变得更加困难（尽管并非不可能）。

在达到速率限制设定的阈值后，例如，我们会收到一个HTTP 429状态码，告诉我们在特定时间段内发出的请求过多。

访问速率限制是应对无限制资源消耗漏洞最常用的反制措施之一。尽管它确实有效，但并不完美：

首先，速率限制本质上是一个滑动条：设置得太宽松则无效，设置得太严格则可能对你的API的良性用户产生负面影响。要找到适合你情况的正确速率限制设置，需要仔细考虑并可能进行一些实验。
其次，在某些情况下，暴露漏洞的不是发出的调用数量，而是单个调用衍生出的问题。例如，如果你能够通过单个调用来执行批量操作（这在GraphQL端点中相当常见），那么你仍然可以通过单个API调用造成很大的破坏。

这对于许多API安全措施来说通常都是如此：它们有助于降低API面临安全问题的风险，但单独来看，它们并不能保证API的安全性。

这一理念甚至有一个专有名称：安全措施中的瑞士奶酪模型。一张图片胜过千言万语：

换句话说，务必采取你的安全防范措施来降低安全风险，但不要单独依赖任何一项防范措施来保护你免受安全事件的影响。