发现 API 的 5 种方法

在处理目标时，最值得测试的部分是其 API。API 是动态的，它们比应用程序的其他部分更新得更频繁，并且负责许多后端繁重的工作。在现代应用程序中，我们通常会看到 REST API，但也会看到其他形式，例如 GraphQL 甚至 SOAP。

当我们第一次接近目标时，我们需要做大量的研究，以了解其主要功能以及它们在幕后的工作方式。当然，我们总是建议花一些时间阅读有关目标及其服务的信息。例如，如果我们要入侵汽车租赁应用程序，那么一开始最好阅读有关该公司的服务（租赁、销售、支持、折扣等）。了解了目标的服务后，我们将寻找其应用程序中反映的功能并尝试破解它们。

为什么要使用特殊的 API 侦察方法而不仅仅是使用应用程序？

需要强调的是，“点击应用显示的每个按钮”是一种很好的做法。理解函数的最简单方法是简单地使用它并分析我们得到的响应。

然而，屏幕上的按钮并不总是包含应用程序包含的全部 API。我们需要假设我们只看到 API 的部分内容，主要有三个原因：

我们不知道具有不同级别权限的用户是否拥有比我们更多的 API
可能存在一些未记录的 API，开发人员尚未为其创建 Web 界面
可能存在开发人员删除了其 Web 界面的旧 API，但仍可在后端运行

进行彻底的 API 侦察的另一个好理由是，这是了解应用程序底层和核心并同时揭露秘密的好方法

1. API 文档

并非总是如此，但在许多情况下，我们攻击的是运行产品（应用程序）的目标，该产品有其 API 的可用文档，如 Swagger 或 WSDL 文件。通常，文档是为了方便其他想要将目标 API 集成到其应用程序中的开发人员使用而存在的。但有时，文档会公开访问，除了过度曝光之外没有任何理由。

无论如何，这是非常有用的信息。它不仅映射了主应用程序的 API 端点，还解释了 API 本身的功能：

特定端点希望获取什么类型的数据（整数/字符串、JSON/XML、POST/PUT/GET 等）
需要发送的标头
我们应该从请求中得到的响应
特定端点所需的身份验证级别

Uber 的 API 文档 — 请求和响应的示例

在上面的例子中，我们可以看到 Uber 如何为其他开发人员提供其 API 文档。注意请求中的不同标头，其中包括一些参数，如授权码、客户端 ID 和客户端密钥。这些参数对于正确执行 API 可能至关重要，文档对此提供了很好的解释。

使用应用程序 API 文档的另一种方法是查找其 Swagger/WSDL 文件。我们不仅可以阅读它们来了解 API 结构，还可以将这些文件加载到 Postman 并开始使用它们！

并非每个应用程序都具有它，但查找和阅读文档可以节省我们的时间并提供有关该应用程序的几乎所有问题的答案。

＃2——API OSINT 研究

正如我们前面提到的，API 是应用程序中非常动态的一部分，并且它会不时发生变化。这意味着两件重要的事情：

开发人员不断开发 API，并可能使用不同的工具来构建、测试和记录不同版本的 API
我们很有可能发现应用程序 API 的旧版本，而且它们可能不如当前生产版本的安全性高！

让我们来讨论一些我们可以轻松使用并快速获得结果的 OSINT 工具。

当我们接近目标时，首先要做的事情之一就是结合使用 Google 的高级搜索选项和一些 API 指示性关键字。快速的 Google dorking 搜索可能会给我们带来：

与 API 相关的目标子域名
目标的 API 文档页面
API 端点——旧版本和当前版本

以下是有关xxx的一些结果示例：

这个简单的搜索当然不能映射xxx的整个 API 表面，但是它为我们提供了更多包含其 API 的公司子域的线索。

一些更有用的搜索表单：

site:target.com inurl:”/v1”
站点：target.com inurl：“/api”
site:target.com inurl:”/graphql”
站点：target.com 标题：“api*‘

WaybackMachine 是用于发现 API 端点并同时获取一些秘密的最出色的工具之一。我们都知道，通过在那里搜索 URL，我们可以在特定日期查看目标页面。神奇的是，我们还可以在 GET 请求中获取 URL 列表。请注意下图：

只需搜索公司的域名并过滤工作“api”，我们就得到了一些 API 端点，甚至包含 GraphQL。

如果我们查看公司的更多子域，我们可能会看到越来越多的 API 端点。在许多情况下，我能够在 Wayback 中找到用户名、令牌、身份验证密钥和 JWT 等凭证。

在 WaybackMachine 中找到了有效的用户令牌

使用找到的这些凭据，我有时可以测试具有不同用户权限的后身份验证 API 端点。

此外，建议在您的侦察自动化中集成GAU或Waymore以拉取更多 API 端点。

GitHub

情况并非总是如此，但如果您的目标有一个您可以访问的 GitHub 存储库，那么花一些时间研究应用程序的代码总是一个好主意。通过几个关键字，我们将最大限度地找到 API 端点及其工作原理的详细说明。

API的一些常见关键字：

/v1
/api
apikey
api_key
apidocs
api_secret
x-api-密钥
/graphql

与 Postman 和 WaybackMachine 一样，在 GitHub 中我们也有机会找到一些可能对下一步合作有用的秘密和凭证。

#3 — 应用程序的 HTML 和 Javascript

为了将 API 请求从前端发送到后端，前端应用程序使用 Javascript 进行 XHR/AJAX 调用。这意味着 API 端点本身应该在客户端源代码中提及。在 FireFox 中，如果我们打开 DevTools（F12）并打开“调试器”选项卡（或 Chrome 中的“源”选项卡），我们将看到目标的地址和一个指向下方的小箭头。单击小箭头，我们将获得前端的资源，包括 Javascript 文件。

TryHackMe 的 Javascript 文件

找到 Javascript 文件后，我们通常会得到一段压缩后的代码，没有新行和空格。这样做是为了提高用户体验的性能。在这种情况下，我们可以使用 JS 美化器，比如这个。之后，只需将代码复制到你的代码编辑器（如 VSCode 或 Sublime）并开始搜索 API 请求。

要在代码中搜索 API 调用，我们首先需要了解应用程序中 API 调用的结构。不要犹豫，花点时间阅读您看到的不同函数和变量。搜索关键字，如API、v1、v2、用户和其他与 API 相关的常用词。另一件事是搜索指示向后端发送请求的 HTTP 方法。

此外，如果我们想要一个自动化工具，我们可以使用Katana。这是一个很好的爬虫，有很多不同的标志可以添加，以便根据我们的目标进行定制。Katana 最重要的功能之一是 Javascript 解析。

4. 主动扫描——模糊测试

到目前为止，我们仅讨论了丰富 API 界面的被动方法，尽量减少与目标本身的接触。被动操作仍然使我们能够发现后端存在的许多甚至大多数 API 端点。但是，当存在不应暴露给我们正在干扰的应用程序的 API 端点时会发生什么？我说的不是影子 API，而是存在于后端的其他端点，这些端点应该为另一个应用程序提供服务，例如内部应用程序或员工应用程序。

例如，当一家公司开发一些前端应用程序（Web 和移动）并从其中一个后端（api.target.com）获取数据时，这种情况就很有意义，例如一个面板供客户使用，另一个面板供经理使用。

模糊测试器

如今，有许多工具可以通过模糊测试很好地发现 API。对于带有端点列表的简单 GET 请求，我们始终可以使用 Burp Intruder、ffuf、GoBuster、Kiterunner等工具，甚至可以构建我们自己的模糊测试器。在大多数情况下，我发现ffuf和 Kiterunner是出色的工具，不仅在速度方面，而且还具有按大小、状态代码、单词等进行过滤的有用功能。具体到 Kiterunner，结合 Assetnote 中的相关列表，该工具非常适合现代 Web 应用程序（NodeJS、Flask、Rails 等）。

只需一个命令，您就可以很好地了解目标的 API 图：

./kr scan https://target.com -w ~/wordlists/routes-large.json

5. 移动端

假设我们的目标是一家快递公司。它有一个网络应用程序，我们可以在其中下订单、付款，甚至使用其他一些功能。但如果快递公司也有移动应用程序，那么可能会有一些专门针对手机的功能，比如通过 GPS 获取准确位置。

在这种情况下，这可能意味着Web 应用程序的 Javascript 中存在的 API 与 APK 文件上存在的 API 端点不同。

移动应用程序渗透测试是一个非常不同的主题，因此我们不会在本文中讨论太多细节，但我们可以使用 JADX 和 MobSF 等静态分析工具来获取驻留在 APK 中的一些硬编码 API 端点。

有一些镜像网站，例如APKPure，我们可以将 APK 下载到我们的机器上，以便使用分析工具打开它。始终建议使用静态和动态分析来映射应用程序发送的每个调用，但首先使用 MobSF 等工具进行初步了解也是非常有效的。

MobSF 是一个自动分析工具，它获取 APK 文件并生成有关文件内部情况的报告：

免费获取网安资料：

申明：本账号所分享内容仅用于网络安全技术讨论，切勿用于违法途径，所有渗透都需获取授权，违者后果自行承担，与本号及作者无关