我最近在一个漏洞赏金计划中发现了一个漏洞，访问控制中的一个小错误使我能够通过不安全的直接对象引用 (IDOR) 漏洞访问敏感的用户数据。
背景
在随意审查一个私人程序时，我注意到目标最近推出了一些围绕用户帐户管理的新功能。
该应用程序允许用户注册账户、管理个人资料以及存储支付信息。尽管攻击面有限，我还是决定花一些时间手动检查该应用程序如何处理标识符和访问控制。我向受害者账户添加了一些虚假的信用卡信息来测试该漏洞。
发现
在渗透测试过程中，我发现该应用程序设置了一个名为的cookie cam=，其中似乎包含一个ID。仔细观察后发现，这个值被用作external_customer_id后端API请求中的。
为了验证应用程序是否执行了适当的访问控制，我创建了两个帐户：
- 受害者（只是在放松，做自己的事情）
- 攻击者（我）
我向受害者的帐户添加了虚假的信用卡详细信息，并拦截了攻击者帐户向以下端点发出的请求：
将攻击者的账户信息替换external_customer_id为受害者的账户信息后id ，我就能从受害者的账户中获取信用卡信息。服务器返回的信息如下：
- 通过卡令牌暴露完整的卡号
- 到期日
- 默认卡状态
端点确认该应用程序容易受到 IDOR 攻击，从而允许未经授权访问敏感用户数据。
当应用程序公开对内部实现对象（例如文件、数据库记录或用户 ID）的引用，并且无法验证用户是否有权访问它时，就会发生 IDOR。
哪里出了问题
没有进行授权检查来验证授权用户是否可以访问对象或数据。
就我而言，为了扩大漏洞的影响，我的目标是检索属于其他用户的 UUID。
务必在密码重置流程、推荐链接和电子邮件跟踪 URL 中测试 UUID 或 ID 的泄露情况。这些 URL 通常会绕过访问控制检查，但其中包含可在之后直接尝试访问对象时重复使用的标识符。
通过侦察增加影响力
为了提升IDOR漏洞的严重性，我收集了该应用程序的存档URL，发现“忘记密码”和一些端点被公开索引。这些URL通常包含JWT令牌或包含诸如此类ID的查询参数external_customer_id。
为此，我使用了两个主要工具：
waybackurls– 从 Wayback Machine 中提取索引 URLgau（获取所有 URL） –从各种公共档案库（包括 Common Crawl、Wayback 等）收集 URL
附加我用来从目标域收集所有 URL 的脚本。
经济侦察很无聊。直到它变得不再无聊。
我们大多数人都会跳过这一步，因为这感觉就像和一个不想玩的人玩捉迷藏。但相信我，侦察阶段是应用程序意外泄露机密的阶段，就像它们试图被黑客入侵一样。
很少有端点reset-password具有 JWT 令牌
在收集了包含类似 JWT 令牌的存档重置密码 URL 后，我使用 Burp Suite 解码器对其进行了分析。解码后，我识别出了诸如externalCustomerId之类的参数，这些参数直接映射到用户帐户。
尽管从存档 URL 中提取的 JWT 令牌已过期且无法用于身份验证，但它们仍然可以被解码以显示其有效负载。
这些提取的 ID 后来被用来利用 IDOR 漏洞并检索信用卡信息。
现在我尝试使用被盗的身份证获取卡数据，你猜怎么着？
这证实了（IDOR）并不是孤立的——它影响了大量用户，大大增加了漏洞的严重性。
意识到这一严重影响后，我立即将调查结果报告给了该项目。
安全团队迅速采取行动，对漏洞进行分类，并在我报告后的数小时内修复了漏洞。
攻击路径:
为何严重程度发生了改变？
其严重性在于，它暴露了系统中存储的真实客户的实时信用卡数据。这不仅仅是理论上的风险或测试数据，信用卡号、到期日期和默认卡状态都是真实的、敏感的财务信息，可能被利用来进行欺诈或身份盗窃。
他们是怎么修复的？
我已确认该问题已修复，开发团队已迅速修复该漏洞，并对处理用户特定数据的后端 API 实施了严格的授权检查。具体而言，他们确保每个访问敏感信息（例如信用卡详细信息）的请求都验证发出请求的用户确实是数据的所有者。
原文始发于微信公众号（安全狗的自我修养）：我如何利用侦察和IDOR攻击来获取数百张信用卡信息
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论