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

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

在这篇文章中，我们将讨论 API 侦察的方法，以便很好地了解我们的攻击面。我们不会在这里深入探讨常见的 API 攻击，因为它将在不同的文章中。

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

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

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

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

进行彻底的 API 侦察的另一个很好的理由是，这是了解应用程序底层和核心并同时公开机密的好方法。在此处阅读更多相关信息。

#1 — API 文档

并非总是如此，但在许多情况下，我们正在破解运行产品、应用程序的目标，该目标具有其 API 的可用文档，例如 WSDL 文件的 Swagger。通常，这些文档是为了方便其他开发人员使用，他们希望将目标的 API 集成到他们的应用程序中。但有时除了过度暴露外，这些文档可以无缘无故地公开访问。

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

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

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

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

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

如果我们的目标没有 API 文档，我们可以毫不费力地为应用程序创建自己的文档。在这篇文章中阅读更多关于它的信息：当目标不存在时，如何为它们制作流氓 API 文档。

#2 — API OSINT 研究

正如我们之前提到的，API 是应用程序中非常动态的一部分，它往往会不时更改。这意味着两件重要的事情：

• 开发人员不断开发 API，并可能使用不同的工具来构建、测试和记录不同 API 的版本
• 我们很有可能可以找到应用程序 API 的旧版本，也许它们不如生产中的当前版本安全！

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

谷歌多尔金

Google 的高级搜索选项和 API 的一些指示性关键字的组合是我们接近目标时首先要做的事情之一。快速的谷歌搜索可能会给我们：

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

以下是有关星巴克的一些结果示例：

当然，这种简单的搜索并不能映射星巴克的整个 API 表面，但它为我们提供了更多指向持有其 API 的公司更多子域的线索。

一些更有用的搜索表单：

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

WaybackMachine的

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

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

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

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

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

邮差

这是开发人员测试其 API 的最常见工具之一，无需前端接口来发送请求，并且比仅使用 curl 方便得多。

Postman 在 postman.com 中可作为 SaaS 应用程序使用，并允许开发人员共享项目，以使团队更轻松。邮递员项目，也称为邮递员收藏，通常被认为是私有的。但是在很多情况下，您会看到这些集合是公开开放的。在集合中，有许多详细信息，例如参数、标头、正文数据、环境变量和授权令牌。

如果我们有幸把手放在目标的邮递员集合上，它可能比找到官方 API 文档页面还要好。这些不仅仅是我们在那里看到的没有真实内容的示例，这些是应用程序开发人员发送的真实请求和来自后端的真实响应。我们可以了解很多关于应用程序的内部环境和目标的底层核心的信息。最好的部分之一 - 通常具有查询后端的高权限的凭据！

在上图中，我们可以看到属于我的一位客户的邮递员系列。如您所见，这是发送到 localhost：8080 的 POST 请求的示例，因为它是在暂存环境中发送的。但是有一个令牌和一个cookie仍然有效，可以在生产中的渗透测试中使用。

GitHub上

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

API 的一些常见关键字：

• /v1
• /应用程序接口
• apikey
• api_key
• API文档
• api_secret
• x-api-密钥
• /graphql

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

#3 — 应用程序的 HTML 和 Javascript

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

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

要在代码中搜索 API 调用，我们首先需要了解 App 中 API 调用的结构。不要犹豫，花一些时间阅读你看到的不同函数和变量。搜索 API、v1、v2、user 等关键字以及与 API 关联的其他常用词。另一件事是搜索指示发送到后端的请求的 HTTP 方法。

此外，如果我们想要一个自动化工具，我们可以使用 Katana。这是一个不错的爬虫，可以添加许多不同的标志，以便为我们的目标自定义它。Katana 最重要的功能之一是 Javascript 解析。有了这个，我们可以在许多 JS 文件上运行，并在几分钟内获得目标上 API 的第一张图片。一个好的建议是使用 Katana 并查看输出，然后再次运行它，并针对特定 Web 应用程序进行更多自定义。

通过查看应用程序的 HTML 和 Javascript，我们可以映射大多数 API 调用，甚至公开影子 API。在我最近的一次参与中，应用程序的用户界面暴露了大约 30 个 API 调用，而在提取 Javascript 代码后，我能够暴露 140 多个 API 端点，这些端点仅通过使用应用程序是无法公开的。

由于影子 API 的暴露量很小，因此它们往往具有更高的漏洞可能性，因为它们也很少被测试。

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

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

例如，当一家公司开发的几个前端应用程序（Web和移动）从一个后端（api.target.com）获取数据时，这种情况是相关的，例如一个面板用于客户端，另一个面板用于经理。

如果我们无法访问其他应用程序，或者我们甚至不知道它的存在，那么通过模糊测试，我们可以找到更多要破解的端点！

当涉及到API模糊测试时，我们需要考虑两件重要的事情：

• 模糊器/扫描仪：基本上，它是发送HTTP请求的工具，并通过响应进行过滤，我们必须预先定义对我们来说感兴趣的内容。
• 单词表：我们模糊的内容。一个好的单词列表是找到一个漏洞只运行通用单词和浪费时间之间的区别。

让我们来谈谈它们。

模糊器

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

使用单个命令，您可以很好地理解目标的 API 图片：

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

此外，除了 API 端点之外，我们还必须发现后端接受哪些参数。当然有合法请求的“默认”参数，但如果也有“影子参数”呢？也许我们可以找到一个 Mass Assignment 漏洞，我们除了模糊目标之外别无他法。对于这项任务，我认为 Arjun 是目前最好的工具之一。

Arjun 是一个 python 工具，它只是使用大量不同的参数向给定的 URL 发送 GET 请求。最后，该工具将为我们提供有效参数列表以供进一步测试。我将在以后关于黑客 API 的文章中写更多关于 Arjun 用法的文章。

单词列表

使用正确的单词表是成功进行 API 渗透测试的关键。对于此任务，有一些很棒的资源：SecLists、Assetnote、FuzzDB 等。

懒惰的黑客会使用通用的单词表，这些单词表只包含大量单词，但没有任何特定目的。专业人士将始终尝试根据目标获得更具体的单词列表。例如，如果我们知道我们的目标是一个基于 Django 作为后端的汽车租赁 Web 应用程序，我们可以将 Django 的通用词表与汽车租赁的自定义词表结合起来。对于第一个单词列表，我们可以使用 assetnote：

第二，我们可以要求 ChatGPT 生成一个用于汽车租赁的常见 API 端点列表：

#5 — 移动端

假设目标是一家快递公司。它有一个 Web 应用程序，我们可以在其中下订单、付款以及更多功能。但是，如果快递公司也有移动应用程序，则有可能有一些功能可能特别适用于手机，例如通过 GPS 获取准确位置。

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

移动应用渗透测试是一个截然不同的话题，因此我们不会在本文中详细介绍，但我们可以使用 JADX 和 MobSF 等静态分析工具来获得驻留在 APK 中的一些硬编码 API 端点。

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

MobSF 是一种自动分析工具，它获取 APK 文件并构建有关文件内部的报告：

从报告中，我们可以获得一些硬编码的 URL 和域，这些 URL 和域可以帮助我们构建目标 API 图片的更大图景。

总结

当我们破解 API 时，我们必须很好地了解应用程序的工作原理、它提供的功能以及可供我们使用的整个表面是什么。通过使用上述方法，我们将彻底构建应用程序的图片，并为破解不同应用程序的 API 奠定良好的基础。

黑客 API 有时更像是一项研究，我们必须使用不同的工具、资源甚至手动技术才能发现它的每一部分。如果我们长时间（数周或数月）专注于一个目标，我们可能会看到它的 API 随着时间的推移而变化和增长，而破解它们的最佳时机是当它们全新或仍处于阴影中时。

原文始发于微信公众号（安全狗的自我修养）：我用来发现 API 的 5 种方法