21、API模糊测试：发现漏洞的有效方法

最新推荐文章于 2025-09-24 09:43:41 发布

blue

最新推荐文章于 2025-09-24 09:43:41 发布

阅读量83

点赞数

CC 4.0 BY-SA版权

分类专栏： API安全攻防实战文章标签： API模糊测试漏洞发现资产管理不当

本文链接：https://blog.youkuaiyun.com/blue/article/details/151666970

API安全攻防实战专栏收录该内容

29 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

API模糊测试：发现漏洞的有效方法

1. 分析有趣的响应

当你注意到一个有趣的响应时，选择该结果并点击“Response”选项卡，以剖析API提供者的响应方式。例如，使用有效负载 {}[]|\:";'<>?,./ 对任何字段进行模糊测试，可能会导致HTTP 400响应代码和 SyntaxError: Unexpected token in JSON at position 32 错误。

一旦遇到这样有趣的错误，你可以改进有效负载，以缩小导致错误的具体原因。如果你找出了导致问题的具体符号或符号组合，可以尝试将其他有效负载与之配对，看看是否能得到更多有趣的响应。例如，如果响应表明存在数据库错误，你可以使用针对这些数据库的有效负载；如果错误表明与操作系统或特定编程语言有关，则使用针对它的有效负载。在这种情况下，错误与意外的JSON令牌有关，因此观察此端点如何处理JSON模糊测试有效负载以及添加额外有效负载时会发生什么是很有趣的。

2. 使用Wfuzz进行深度模糊测试

如果你使用的是Burp Suite CE，Intruder会限制你发送请求的速率，因此在发送大量有效负载时，你应该使用Wfuzz。一开始，使用Wfuzz发送大型POST或PUT请求可能会让人望而生畏，因为你需要在命令行中正确添加大量信息。不过，掌握一些技巧后，你应该能够在Burp Suite CE和Wfuzz之间轻松切换。

Wfuzz的一个优点是它比Burp Suite快得多，因此我们可以增加有效负载的大小。以下示例使用了一个名为 big-list-of-naughty-strings.txt 的SecLists有效负载，其中包含500多个值：

$ wfuzz -z file,/home/hapihacker/big-list-of-naughty-strings.txt

下面我们逐步构建Wfuzz命令：
1. 为了与上一节中Burp Suite的示例相匹配，我们需要包含 Content-Type 和 x-access-token 头，以便从API获得经过身份验证的结果。每个头使用 -H 选项指定，并使用引号括起来：

$ wfuzz -z file,/home/hapihacker/big-list-of-naughty-strings.txt -H "Content-Type: application/json" -H "x-access-token: [...]"

注意请求方法是PUT，你可以使用 -X 选项指定它。此外，为了过滤掉状态码为400的响应，使用 --hc 400 选项：

$ wfuzz -z file,/home/hapihacker/big-list-of-naughty-strings.txt -H "Content-Type: application/json" -H "x-access-token: [...]" -p 127.0.0.1:8080:HTTP --hc 400 -X PUT

要使用Wfuzz对请求体进行模糊测试，使用 -d 选项指定请求体，并将其粘贴到命令中，用引号括起来。注意，Wfuzz通常会删除引号，因此使用反斜杠来保留它们在请求体中。像往常一样，我们将想要模糊测试的参数替换为 FUZZ 。最后，使用 -u 指定要攻击的URL：

$ wfuzz -z file,/home/hapihacker/big-list-of-naughty-strings.txt -H "Content-Type: application/json" -H "x-access-token: [...]" --hc 400 -X PUT -d "{
    \"user\": \"FUZZ\",
    \"pass\": \"FUZZ\",
    \"id\": \"FUZZ\",
    \"name\": \"FUZZ\",
    \"is_admin\": \"FUZZ\",
    \"account_balance\": \"FUZZ\"
}" -u http://192.168.195.132:8090/api/user/edit_info

这个命令比较长，很容易出错。如果你需要进行故障排除，我建议将请求代理到Burp Suite，这有助于你可视化正在发送的请求。要将流量代理回Burp，使用 -p 代理选项，指定你的IP地址和Burp Suite运行的端口：

$ wfuzz -z file,/home/hapihacker/big-list-of-naughty-strings.txt -H "Content-Type: application/json" -H "x-access-token: [...]" -p 127.0.0.1:8080 --hc 400 -X PUT -d "{
    \"user\": \"FUZZ\",
    \"pass\": \"FUZZ\",
    \"id\": \"FUZZ\",
    \"name\": \"FUZZ\",
    \"is_admin\": \"FUZZ\",
    \"account_balance\": \"FUZZ\"
}" -u http://192.168.195.132:8090/api/user/edit_info

在Burp Suite中，检查拦截到的请求并将其发送到Repeater，查看是否有拼写错误或其他错误。如果你的Wfuzz命令正常运行，运行它并查看结果，结果应该如下所示：

********************************************************
* Wfuzz - The Web Fuzzer                         *
********************************************************
Target: http://192.168.195.132:8090/api/user/edit_info
Total requests: 502
==========================================================
ID           Response   Lines    Word       Chars       Payload
==========================================================
000000001:   200        0 L      3 W        39 Ch       "undefined - undefined - undefined - undefined - undefined - undefined"
000000012:   200        0 L      3 W        39 Ch       "TRUE - TRUE - TRUE - TRUE - TRUE - TRUE"
000000017:   200        0 L      3 W        39 Ch       "\\ - \\ - \\ - \\ - \\ - \\"
000000010:   302        10 L    63 W        1014 Ch       "<a href='\xE2\x80..."

现在你可以找出异常情况，并进行额外的请求以分析你所发现的问题。在这种情况下，值得看看API提供者对导致302响应代码的有效负载有何反应。可以在Burp Suite的Repeater或Postman中使用此有效负载。

3. 广泛模糊测试以发现资产管理不当漏洞

当一个组织暴露已退役、处于测试环境或仍在开发中的API时，就会出现资产管理不当漏洞。在这些情况下，这些API很可能比其受支持的生产版本的保护措施更少。资产管理不当可能只影响单个端点或请求，因此广泛进行模糊测试以检查API中是否存在任何请求的资产管理不当问题通常是很有用的。

要广泛进行此问题的模糊测试，最好有API的规范或集合文件，以便在Postman中进行请求。本节假设你有一个可用的API集合。

除了使用文档，你还可以通过模糊测试发现资产管理不当漏洞。其中一个最好的方法是观察业务逻辑中的模式并验证你的假设。例如，在一个示例中，集合中所有请求使用的 baseURL 变量是 https://petstore.swagger.io/v2 。你可以尝试将 v2 替换为 v1 ，并使用Postman的Collection Runner进行测试。

示例API的生产版本是 v2 ，因此测试一些关键字，如 v1 、 v3 、 test 、 mobile 、 uat 、 dev 和 old ，以及在分析或侦察测试中发现的任何有趣路径是个好主意。此外，一些API提供者会通过在版本号前后添加 /internal/ 来允许访问管理功能，例如：
- /api/v2/internal/users
- /api/internal/v2/users

如前面所述，首先使用Collection Runner和API的预期版本路径，为API对典型请求的响应建立一个基线。了解API对成功请求和失败请求（或对不存在资源的请求）的响应方式。

为了便于测试，我们设置一个状态码为200的测试，就像本章前面所做的那样。如果API提供者通常对不存在的资源返回状态码404，那么对这些资源的200响应很可能表明API存在漏洞。确保在集合级别插入此测试，这样在使用Collection Runner时，每个请求都会运行该测试。

现在保存并运行你的集合。检查通过此测试的任何请求的结果。审查结果后，更换新的关键字并重复此过程。如果你发现了资产管理不当漏洞，下一步将是测试非生产端点是否存在其他弱点。

以下是一个简单的流程图，展示了广泛模糊测试的步骤：

graph TD;
    A[开始] --> B[建立API响应基线];
    B --> C[设置状态码测试];
    C --> D[保存并运行集合];
    D --> E[检查结果];
    E --> F{是否发现漏洞};
    F -- 是 --> G[测试非生产端点];
    F -- 否 --> H[更换关键字重复测试];
    G --> I[结束];
    H --> D;

4. 使用Wfuzz测试请求方法

模糊测试的一个实际应用是确定给定API请求可用的所有HTTP请求方法。你可以使用我们介绍过的几种工具来完成此任务，本节将使用Wfuzz进行演示。

首先，捕获或构建你想要测试其可接受HTTP方法的API请求。例如，我们使用以下请求：

GET /api/v2/account HTTP/1.1
HOST: restfuldev.com
User-Agent: Mozilla/5.0
Accept: application/json

然后，使用Wfuzz创建请求，使用 -X FUZZ 专门对HTTP方法进行模糊测试。运行Wfuzz并查看结果：

$ wfuzz -z list,GET-HEAD-POST-PUT-PATCH-TRACE-OPTIONS-CONNECT- -X FUZZ http://testsite.com/api/v2/account

结果如下：

********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************
Target: http://testsite.com/api/v2/account
Total requests: 8
==========================================================
ID           Response   Lines    Word       Chars       Payload
==========================================================
000000008:   405        7 L      11 W       163 Ch      "CONNECT"
000000004:   405        7 L      11 W       163 Ch      "PUT"
000000005:   405        7 L      11 W       163 Ch      "PATCH"
000000007:   405        7 L      11 W       163 Ch      "OPTIONS"
000000006:   405        7 L      11 W       163 Ch      "TRACE"
000000002:   200        0 L      0 W        0 Ch        "HEAD"
000000001:   200        0 L      107 W      2610 Ch     "GET"
000000003:   405        0 L      84 W       1503 Ch     "POST"

从这些结果可以看出，基线响应通常包含405状态码（方法不允许）和163个字符的响应长度。异常响应包括两个状态码为200的请求方法。这证实了GET和HEAD请求都可以正常工作，这并没有揭示太多新信息。然而，此测试还表明，你可以对 api/v2/account 端点使用POST请求。如果你测试的API文档中未包含此请求方法，那么你可能发现了非预期的功能。未记录的功能是一个很好的发现，应该对其进行额外的漏洞测试。

5. 深度模糊测试以绕过输入过滤

在进行深度模糊测试时，你需要策略性地设置有效负载位置。例如，对于PUT请求中的电子邮件字段，API提供者可能会很好地要求请求体的内容符合电子邮件地址的格式。换句话说，任何不是电子邮件地址的值都可能导致相同的400错误请求错误。类似的限制可能也适用于整数和布尔值。如果你已经彻底测试了一个字段，但没有得到任何有趣的结果，你可以考虑在后续测试中排除该字段，或者在单独的攻击中进行更彻底的测试。

为了更深入地对特定字段进行模糊测试，你可以尝试绕过现有的限制。这里的绕过是指欺骗服务器的输入过滤代码，使其处理通常会被限制的有效负载。以下是一些针对受限字段的技巧：
1. 尝试发送符合受限字段格式的内容（如果是电子邮件字段，包含一个看起来有效的电子邮件），添加一个空字节，然后添加另一个用于插入模糊测试有效负载的位置。例如：

"user": "a@b.com%00§test§"

除了空字节，还可以尝试发送管道符（ | ）、引号、空格和其他转义符号。更好的做法是，由于可能发送的符号很多，你可以添加第二个有效负载位置用于常见的转义字符，例如：

"user": "a@b.com§escape§§test§"

使用一组潜在的转义符号作为 §escape§ 有效负载，将你想要执行的有效负载作为 §test§ 。要进行此测试，可以使用Burp Suite的集群炸弹攻击，它会遍历多个有效负载列表，并尝试将每个其他有效负载与之匹配：

Escape1
Escape1
Escape1
Escape2
Escape2
Escape2
Payload1
Payload2
Payload3
Payload1
Payload2
Payload3

集群炸弹模糊测试攻击非常适合穷尽某些有效负载组合，但要注意请求数量会呈指数级增长。

6. 模糊测试目录遍历漏洞

另一个可以通过模糊测试发现的弱点是目录遍历漏洞。目录遍历也称为路径遍历，是一种允许攻击者使用 ../ 等表达式将Web应用程序导向父目录，然后读取任意文件的漏洞。你可以使用一系列路径遍历的点和斜杠来替代上一节中描述的转义符号，例如：
- ..
- ..\
- ../
- \..\
- \..\.\

这个漏洞已经存在多年，通常会有各种安全控制措施，包括用户输入过滤来防止它，但使用正确的有效负载，你可能能够绕过这些控制和Web应用程序防火墙。如果你能够离开API路径，你可能能够访问敏感信息，如应用程序逻辑、用户名、密码和其他个人身份信息（如姓名、电话号码、电子邮件和地址）。

目录遍历可以使用广泛和深度模糊测试技术进行。理想情况下，你应该对API的所有请求进行深度模糊测试，但由于这是一项巨大的任务，你可以先进行广泛模糊测试，然后专注于特定的请求值。确保使用从侦察、端点分析和包含错误或其他信息披露的API响应中收集的信息来丰富你的有效负载。

7. 实验：针对crAPI的资产管理不当漏洞模糊测试

在这个实验中，你将对crAPI进行模糊测试，以检验你的技能。如果你还没有这样做，请像之前一样构建一个crAPI的Postman集合，并获取一个有效的令牌。现在我们可以先进行广泛模糊测试，然后根据发现的结果转向深度模糊测试。

首先，使用Postman对各种API版本进行广泛模糊测试。打开Postman，导航到环境变量（使用Postman右上角的眼睛图标作为快捷方式）。在Postman环境中添加一个名为 path 的变量，并将其值设置为 v3 。现在你可以更新它来测试各种与版本相关的路径（如 v1 、 v2 、 internal 等）。

为了从Postman的Collection Runner获得更好的结果，我们使用Collection Editor配置一个测试。选择crAPI集合选项，选择“Edit”，然后选择“Tests”选项卡。添加一个测试，用于检测何时返回状态码404，这样任何不导致404未找到响应的请求都会显得异常。你可以使用以下测试：

pm.test("Status code is 404", function () {
    pm.response.to.have.status(404);
});

使用Collection Runner对crAPI集合进行基线扫描。首先，确保你的环境是最新的，并勾选“Save Responses”。

由于我们正在寻找资产管理不当漏洞，我们只测试路径中包含版本信息的API请求。使用Postman的查找和替换功能，将集合中的 v2 和 v3 值替换为 path 变量。

你可能会注意到集合中的一个有趣现象：除了密码重置端点 /identity/api/auth/v3/check-otp 使用 v3 外，所有端点的路径中都使用 v2 。

现在变量设置好了，使用一个我们预期会失败的路径进行基线扫描。例如，将 path 变量的当前值设置为 fail12345 ，这在任何端点中都不太可能是有效的值。了解API在失败时的反应将有助于我们理解API对不存在路径的请求的响应方式。这个基线将有助于我们使用Collection Runner进行广泛模糊测试。如果对不存在路径的请求返回200成功响应，我们需要寻找其他指标来检测异常。

如预期的那样，基线扫描显示所有九个请求都失败了测试，因为API提供者返回了404状态码。现在，当测试路径如 test 、 mobile 、 uat 、 v1 、 v2 和 v3 时，我们可以轻松地发现异常。要快速更新变量，点击Postman右上角的眼睛图标。

当你将 path 变量的值设置为 /v2 和 /v3 时，情况会变得有趣起来。当 path 变量设置为 /v3 时，所有请求都失败了测试。这有点奇怪，因为我们之前注意到密码重置请求使用的是 /v3 。为什么现在这个请求失败了呢？根据Collection Runner，密码重置请求实际上收到了500内部服务器错误，而其他所有请求都收到了404未找到状态码。这是一个异常情况！

进一步调查密码重置请求会发现，使用 /v3 路径时会发出HTTP 500错误，因为应用程序有一个控制，限制了你发送一次性密码（OTP）的尝试次数。向 /v2 发送相同的请求也会导致HTTP 500错误，但响应稍大一些。在Burp Suite中重新尝试这两个请求，并使用Comparer查看细微的差异可能是值得的。 /v3 密码重置请求的响应是 {"message":"ERROR..","status":500} ，而 /v2 密码重置请求的响应是 {"message":"Invalid OTP! Please try again..","status":500} 。

密码重置请求与我们建立的基线不符，即当URL路径未使用时返回404状态码。相反，我们发现了一个资产管理不当漏洞！此漏洞的影响是， /v2 对我们猜测OTP的次数没有限制。对于一个四位OTP，我们应该能够通过深度模糊测试在10,000次请求内发现任何OTP。最终，你会收到一条消息，表明你成功了： {"message":"OTP verified","status":200} 。

综上所述，模糊测试是发现API漏洞的一种非常有效的技术。通过广泛和深度模糊测试，我们可以发现资产管理不当、输入过滤不足、目录遍历等多种漏洞。在实际应用中，我们需要根据具体情况选择合适的工具和方法，并仔细分析测试结果，以发现潜在的安全问题。

以下是一个总结模糊测试流程的表格：
| 测试类型 | 步骤 | 工具 |
| ---- | ---- | ---- |
| 广泛模糊测试 | 1. 建立API响应基线；2. 设置状态码测试；3. 保存并运行集合；4. 检查结果；5. 更换关键字重复测试 | Postman |
| 深度模糊测试 | 1. 策略性设置有效负载位置；2. 尝试绕过输入过滤；3. 使用集群炸弹攻击 | Burp Suite、Wfuzz |
| 目录遍历模糊测试 | 1. 使用路径遍历符号作为有效负载；2. 结合侦察信息丰富有效负载 | Wfuzz |
| 资产管理不当漏洞测试 | 1. 构建Postman集合；2. 配置状态码测试；3. 进行基线扫描；4. 更换路径变量测试；5. 分析异常结果 | Postman、Burp Suite |

API模糊测试：发现漏洞的有效方法

8. 模糊测试结果分析

在完成各种模糊测试后，对结果的分析至关重要。通过分析结果，我们可以确定哪些请求导致了异常响应，进而发现潜在的漏洞。以下是一些分析模糊测试结果的要点：
- 识别异常响应 ：重点关注与基线响应不同的状态码、响应长度、响应内容等。例如，在测试请求方法时，405状态码是常见的基线响应，而200状态码则可能表示存在未记录的功能。
- 关联请求和漏洞类型 ：根据异常响应的特征，推测可能存在的漏洞类型。如返回数据库错误信息可能暗示SQL注入漏洞，返回文件内容可能与目录遍历漏洞有关。
- 复现和验证 ：对于发现的异常情况，使用Burp Suite的Repeater或Postman等工具复现请求，验证漏洞的存在。同时，尝试不同的有效负载和参数组合，进一步探索漏洞的影响范围。

以下是一个简单的结果分析流程图：

graph TD;
    A[获取模糊测试结果] --> B[识别异常响应];
    B --> C{是否存在异常};
    C -- 是 --> D[关联请求和漏洞类型];
    D --> E[复现和验证漏洞];
    C -- 否 --> F[结束分析];
    E --> G[记录漏洞信息];
    G --> F;

9. 模糊测试的注意事项

在进行API模糊测试时，有一些注意事项需要牢记，以确保测试的有效性和安全性。
- 合法合规 ：在进行模糊测试之前，确保你已经获得了目标系统所有者的授权。未经授权的测试可能会违反法律法规，并导致严重的后果。
- 控制测试范围 ：合理控制测试的范围和强度，避免对生产系统造成不必要的影响。可以先在测试环境中进行测试，然后逐步扩展到生产环境。
- 监控系统状态 ：在测试过程中，密切监控目标系统的状态，如CPU使用率、内存占用、网络流量等。如果发现系统出现异常，应立即停止测试。
- 备份数据 ：在进行可能会修改或删除数据的测试之前，务必备份相关数据，以防止数据丢失。

10. 总结与建议

API模糊测试是一种强大的技术，可以帮助我们发现各种API漏洞。通过广泛和深度模糊测试，我们可以全面地测试API的安全性，找出潜在的风险点。以下是一些总结和建议：
- 综合运用多种测试方法 ：结合广泛模糊测试和深度模糊测试，以及其他安全测试技术，如静态代码分析、动态分析等，提高漏洞发现的概率。
- 持续测试 ：API的安全性是一个持续的过程，随着系统的更新和变化，新的漏洞可能会出现。因此，定期进行模糊测试，确保API的安全性始终得到保障。
- 团队协作 ：模糊测试通常需要多个团队成员的协作，包括开发人员、测试人员、安全专家等。加强团队之间的沟通和协作，共同解决发现的问题。
- 学习和分享 ：关注行业动态和最新的安全技术，不断学习和掌握新的模糊测试技巧。同时，与同行分享经验和成果，共同提高API安全测试的水平。

以下是一个总结模糊测试要点的表格：
| 要点 | 说明 |
| ---- | ---- |
| 测试方法 | 广泛模糊测试、深度模糊测试、目录遍历模糊测试等 |
| 工具选择 | Burp Suite、Wfuzz、Postman等 |
| 结果分析 | 识别异常响应、关联漏洞类型、复现验证 |
| 注意事项 | 合法合规、控制范围、监控状态、备份数据 |
| 建议 | 综合运用方法、持续测试、团队协作、学习分享 |

通过遵循这些要点和建议，我们可以更有效地进行API模糊测试，提高API的安全性，保护用户的数据和隐私。希望本文对你理解和应用API模糊测试技术有所帮助。