亲爱的，你是不是又把API暴露在外了？ | 作者：LS - Medium

发现API暴露漏洞的经验分享

在本文中，我将分享我在一个漏洞奖励计划中发现的几个访问控制漏洞的经历。这些漏洞虽然看似简单，但每个漏洞的发现过程都各有特点。希望通过分享我的技巧和思考过程，能为大家提供一些启发。

初识目标系统

目标是一个名为 shop.com 的零售网站。在测试过程中，我发现了一个子域 ecom.shop.com，这是一个用于处理内部零售业务的电子商务后端 API。

当我尝试访问 ecom.shop.com 时，尽管我在主站点有一个活动会话，但系统返回了 401 Unauthorized 错误，并提示“缺少标头：授权”。主站点使用 Cookie 进行身份验证，因此我尝试将 Cookie 作为令牌发送，结果遇到了“缺少 OAuth 令牌”的错误提示。后端返回的这些详细错误信息，虽然对开发者来说是调试利器，但对攻击者来说却是潜在的漏洞入口。

利用模糊测试发现隐藏端点

通过对主站点的 Cookie 进行 URL 解码后，我以 Authorization: OAuth [cookie] 的格式发送请求，这次返回了 404 Not Found，而不是 401 Unauthorized。这表明我已经能够与后端 API 交互。

随后，我使用 FFUF 工具结合 SecLists 的基本单词表对 ecom.shop.com 进行模糊测试。在测试过程中，我发现了一个名为 “备份” 的目录，并获得了 303 Redirect 的响应。这进一步确认了后端存在未保护的资源。

深入挖掘：从备份目录到敏感操作

在备份目录中，我发现了多个 HTML 文件，这些文件似乎是客户服务系统的一部分。其中一个 HTML 文件暴露了一个接受 POST 请求的端点 /v2/issueFund，并在 AJAX 调用中清楚地列出了所需的参数：[agent](https://www.explinks.com/wiki/what-is-an-ai-agent/) 和 orderNumber。

通过发送一个包含真实订单号的 POST 请求，我成功触发了退款操作，并收到了 200 OK 的响应。不久后，我的信用卡费用被成功退回，验证了漏洞的影响。

发现更多端点和数据泄露

在进一步模糊测试中，我注意到一个名为 /v1/promo 的端点返回了 404 错误，但其内容长度与其他无效端点不同。这种异常引起了我的注意。

通过尝试在请求中添加 id 参数，我意外发现了一个漏洞：当 id 参数为空时，系统会返回所有促销代码的完整列表。这些促销代码中包括一些内部员工专用的优惠码。

为了验证是否可以编辑这些促销代码，我尝试发送 POST 请求，并根据返回的错误提示补充了所需的参数（如 name、startDate 等）。最终，我成功地修改了促销代码，甚至可以创建自定义的折扣规则。

利用 POST 方法发现隐藏端点

在模糊测试中，我发现了另一个有趣的现象：某些端点（如 /v1/serviceordersystem）在使用 POST 请求时会返回异常响应。通过进一步测试，我发现这些端点可以通过空的 id 参数返回系统中所有服务订单的详细信息。

虽然这些服务订单本身并不包含敏感信息，但我尝试修改订单数据，并成功覆盖了其中的内容。这种操作如果被恶意利用，可能会对目标系统的正常运营造成严重影响。

总结与反思

通过这次漏洞挖掘，我总结出以下几点经验：

留意异常行为：漏洞往往隐藏在与规范不符的细节中，记录这些异常并深入分析，可能会有意想不到的发现。
模糊测试技巧：在使用工具进行模糊测试时，确保匹配所有响应代码（如使用 FFUF 的 -mc ALL 参数），以免遗漏潜在的漏洞。
身份验证绕过：尝试不同类型的身份验证方式（如移动应用生成的令牌），可能会意外发现高权限的访问途径。
参数测试：当遇到 401 或 403 错误时，可以尝试更改参数类型（如空值、字符串、整数等），有时系统会返回更多的调试信息。

最后，虽然这些漏洞的修复过程让我感到遗憾，但这次经历让我学到了很多，也让我在漏洞奖励计划的排行榜上取得了不错的成绩。

免责声明

本文中的所有测试均在授权范围内进行，且所有修改均已恢复至原始状态。请勿在未经授权的情况下尝试类似操作。

原文链接: https://medium.com/@l_s_/honey-you-left-the-apis-open-again-c382a3a2d917