GraphQL API 漏洞

GraphQL 的漏洞通常是由实现和设计缺陷引起的。例如，内省功能可能处于启用状态，这会让攻击者能够查询 API 以获取有关其架构的信息。

GraphQL 攻击通常表现为恶意请求，这能让攻击者获取数据或执行未经授权的操作。此类攻击可能会造成严重后果，尤其是当用户能够通过操纵查询或执行 CSRF 攻击来获取管理员权限时。易受攻击的 GraphQL API 还可能导致信息泄露问题。

在本节中，我们将探讨如何测试 GraphQL API。如果您不熟悉 GraphQL 也无需担心，我们会在讲解过程中介绍相关细节。我们还提供了一些实验，以便您练习所学内容。

寻找GraphQL端点

在测试 GraphQL API 之前，您首先需要找到其端点。由于 GraphQL API 对所有请求都使用相同的端点，因此这是非常有价值的信息。

注意

本节介绍如何手动探测 GraphQL 端点。不过，Burp Scanner 可以在其扫描过程中自动测试 GraphQL 端点。如果发现任何此类端点，它会报告“发现 GraphQL 端点”问题。

通用查询

如果你向任何GraphQL端点发送查询query { __typename }，它将在响应的某个地方包含字符串{"data": {"__typename": "query"}}。这被称为通用查询，是检测一个URL是否对应于GraphQL服务的有用工具.

该查询之所以有效，是因为每个GraphQL端点都有一个名为__typename的保留字段，该字段返回被查询对象的类型作为字符串.

常见端点名称

GraphQL服务通常使用类似的端点后缀。在测试GraphQL端点时，你应该尝试向以下位置发送通用查询：

• /graphql

• /api

• /api/graphql

• /graphql/api

• /graphql/graphql

如果这些常见端点没有返回GraphQL响应，你还可以尝试在路径后面添加/v1。

注意

GraphQL服务通常会对任何非GraphQL请求返回“查询不存在”或类似的错误。在测试GraphQL端点时，你应该注意这一点。

请求方法

尝试寻找GraphQL端点的下一步是使用不同的请求方法进行测试。

对于生产环境中的GraphQL端点，最佳实践是只接受内容类型为application/json的POST请求，因为这有助于防止跨站请求伪造（CSRF）漏洞。然而，一些端点可能会接受其他方法，例如GET请求或使用x-www-form-urlencoded内容类型的POST请求。

如果你通过向常见端点发送POST请求找不到GraphQL端点，尝试使用其他HTTP方法重新发送通用查询。

初步测试

一旦你发现了端点，你可以发送一些测试请求，以更好地了解其工作方式。如果该端点为网站提供支持，尝试在Burp的浏览器中探索Web界面，并使用HTTP历史记录来检查发送的查询。

利用未经过滤的参数

在寻找漏洞时，测试查询参数是一个很好的起点。

如果API使用参数直接访问对象，它可能容易受到访问控制漏洞的影响。用户可能只需提供一个与该信息对应的参数，就能访问到他们本不应访问的信息.这有时被称为不安全的直接对象引用（IDOR）.

例如，以下查询请求一个在线商店的产品列表：

返回的产品列表仅包含已列出的产品。

从这些信息中，我们可以推断出以下几点：

• 产品被分配了连续的ID.

• 产品ID 3不在列表中，可能是因为它已经被下架.

• 通过查询缺失产品的ID，我们可以获取其详细信息，即使它不在商店中列出，也没有被原始产品查询返回.

发现模式信息

测试API的下一步是拼凑关于底层模式的信息。

最好的方法是使用内省查询。内省是GraphQL内置的一个功能，它允许你查询服务器以获取有关模式的信息。

内省帮助你了解如何与GraphQL API进行交互。它还可能披露一些敏感数据，例如描述字段。

使用内省

要使用内省来发现模式信息，查询__schema字段。这个字段在所有查询的根类型上都是可用的。

与常规查询一样，当你运行内省查询时，可以指定你希望返回的响应的字段和结构。例如，你可能希望响应中只包含可用的变异名称。

注意

Burp Suite可以为你生成内省查询。有关更多信息，请参阅使用内省访问GraphQL API模式(