Razorpay二维码IDOR漏洞分析

本文讲述我在Razorpay的QR码支付系统中发现的IDOR（不安全的直接对象引用）漏洞，该漏洞已通过HackerOne平台报告。本文旨在分享我的发现过程，记录漏洞详情，并听取安全社区对漏洞分类的意见。

漏洞详情

Razorpay API端点：

1

GET /merchant/api/live/payments/qr_codes/{qr_id}/payments

当提供有效的qr_id时，该端点返回敏感的客户支付详细信息（UPI ID、账户标识符、时间戳、交易历史记录）。

实际上：如果攻击者拥有qr_id，就可以在没有适当授权的情况下检索客户交易数据。

qr_id的获取方式

公开暴露：QR码本意是供商家分享的（在YouTube演示等场合展示）。

OSINT档案：使用Wayback Machine，我发现了包含有效qr_id值的已存档Razorpay仪表板页面。

这表明qr_id并不像声称的那样保密。一旦暴露，攻击者就可以滥用它。

概念验证

1. 从公开分享的QR码或存档的Razorpay页面获取qr_id
2. 调用端点：GET /merchant/api/live/payments/qr_codes/{qr_id}/payments

API响应包含多个客户支付详细信息的JSON数据：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

{
  "id": "redacted",
  "entity": "payment",
  "amount": 1000,
  "currency": "INR",
  "base_amount": 1000,
  "status": "captured",
  "order_id": null,
  "invoice_id": null,
  "international": false,
  "method": "upi",
  "amount_refunded": 0,
  "amount_transferred": 0,
  "refund_status": null,
  "captured": true,
  "description": "redacted",
  "card_id": null,
  "bank": null,
  "wallet": null,
  "vpa": "redacted@ybl",
  "email": "redacted",
  "contact": "redacted",
  "notes": [],
  "fee": 1,
  "tax": 0,
  "error_code": null,
  "error_description": null,
  "error_source": null,
  "error_step": null,
  "error_reason": null,
  "acquirer_data": {
    "rrn": "redacted"
  },
  "created_at": 1726534884,
  "account_id": "redacted",
  "upi": {
    "payer_account_type": "bank_account",
    "vpa": "redacted@ybl"
  }
}

这清楚地证明了存在信息泄露的IDOR漏洞。

Razorpay的响应

Razorpay承认了该问题并部署了修复程序（该端点现在返回错误）：

1
2
3
4
5

{
  "status_code": 400,
  "success": false,
  "errors": ["The id provided does not exist"]
}

但在审查后，他们在HackerOne上将报告关闭为"信息类"。

他们的理由是：

• qr_id是高熵标识符，旨在保持机密
• 商家有责任保护它
• 基于OSINT/Wayback的发现不在其项目规则范围内

我的观点

虽然我尊重他们的立场，但我认为严重性更高：

设计缺陷，而非商家错误：QR码本质上是公开的。假设qr_id保密性是一种薄弱的设计。

敏感数据泄露：客户支付详细信息直接暴露——不仅仅是元数据。

现实世界可发现性：Wayback Machine中存档的Razorpay仪表板页面暴露了有效的ID。这不是暴力破解，而是OSINT。

已部署修复：如果这真的是"信息类"，就没有必要打补丁。

经验教训

研究人员：始终检查范围规则——有些项目排除了OSINT或第三方档案。

组织：当这些值自然共享或可能被存档时，不要依赖"秘密"标识符。

社区：信息类和中等严重性之间存在灰色地带。现实世界的利用风险很重要。

最终想法

本报告通过HackerOne负责任地提交。Razorpay修复了这个弱点，这最终是一个积极的结果。

但将其分类为信息类为社区提出了一个重要问题：👉 当敏感的客户数据可能通过IDOR暴露时，基于OSINT的复现是否应该排除其被认定为有影响力？

我很想听听其他研究人员的想法。这真的是信息类，还是更接近中等/高严重性问题？

Instagram: https://www.instagram.com/rootx_narayanan/ Twitter: https://twitter.com/itsnarayananm