
不安全的直接对象引用(IDOR)是 Web 应用程序中一种常见的安全漏洞,若管理不当,可能引发严重的安全风险。这类漏洞的本质是应用程序允许用户直接访问内部对象(如数据库记录或文件),却没有验证该用户是否具备相应的操作权限。
简单来说,如果攻击者找到了这些对象的引用标识,他们就能在未获授权的情况下访问甚至篡改这些资源。IDOR 本质上属于访问控制缺陷,当应用未能正确校验用户对某个资源的访问权限时,漏洞便会产生。其后果可能包括敏感数据泄露、非授权的数据修改以及用户账户安全受损。
根据 Bugcrowd 的漏洞评级分类(VRT),IDOR 问题的严重性取决于所暴露数据的敏感度以及未授权访问可能造成的影响,其评级范围可从高危(P1)至低危(P5)。
了解了 IDOR 的基本概念后,我们来探讨在实际测试中,可以从哪些关键端点入手寻找这类安全漏洞。
利用哈希或编码值
- 当你发现请求中的 ID 参数被编码(如 Base64、Hex 等)时,首要步骤是尝试解码。例如,遇到类似
userId=MTIzNA== 的参数,解码后可能得到明文 ID 1234。之后,便可以尝试修改该 ID 值进行越权测试。为了加深理解,可以参考相关技术视频进行学习。
- 另一种常见场景是,当请求中未包含有效的授权令牌(如 Bearer Token),或者应用未对 Cookie 进行严格校验时,你可以尝试直接将攻击者的
userId 替换为受害者的 userId,观察是否能以受害者身份执行操作。
上传头像功能
- 在用户上传头像时,务必拦截并仔细检查请求体。如果其中包含用户 ID 参数,尝试修改它为其他用户的 ID。如果成功,则意味着你可能将头像上传到了他人账户,这构成了一个典型的 IDOR 漏洞。部分公开的渗透测试案例视频对此有详细演示。
尝试更改邮箱或用户名
- 案例一:邮箱更改漏洞
如果你能更改其他用户的绑定邮箱,这通常会导致账户接管,属于 P1 级别的高危漏洞。典型的利用链条是:攻击者首先尝试修改自己的手机或邮箱,拦截请求后发现存在可控的 ID 参数;将其更改为目标受害者的 ID 并发送请求,若成功,则意味着攻击者控制了受害者的邮箱。随后,攻击者可在登录页面使用“忘记密码”功能,向自己控制的邮箱申请重置密码,从而完全接管账户。
- 案例二:用户名更改漏洞
攻击者在修改自己用户名时拦截请求,简单地将请求中的自身 ID 替换为受害者 ID。如果请求成功执行并更改了受害者的用户名,这也构成了一个 IDOR 漏洞。此类漏洞的具体影响因应用程序的业务逻辑而异。
文件下载功能
- 切勿忽略文件下载接口。请求可能形如
GET /attachment/1234,只需尝试递增或修改附件 ID,就有可能下载到其他用户的私有文件。在某些情况下,这可能造成包含个人身份信息(PII)等重要文件的泄露。
取消订阅功能
- 攻击者可以将请求中的邮箱参数替换为受害者的邮箱,然后触发“取消订阅”操作。成功的话,可能导致受害者的邮箱被从所有订阅或通知列表中移除。相关技术文章和视频对此有详细报道。
以上列举了一些寻找 IDOR 漏洞的主要攻击面。为了帮助你更系统地进行学习和测试,这里推荐一个非常全面的资源库:All-about-IDOR。值得注意的是,前文提及的多数演示视频链接都已汇总在该资源库中。
这个仓库几乎汇集了关于 IDOR 的所有核心资源,包括 50 多个实战演示视频、来自 HackerOne 的漏洞报告、技术分析文章、各种绕过技巧以及 IDOR 的细分知识点。对于致力于提升渗透测试技能的安全从业者而言,这是一个极佳的学习宝库。
通过研究和实践这些资源,你将能够建立起对 IDOR 漏洞的深刻理解。掌握这些知识后,你便能更有针对性地在安全测试中挖掘此类漏洞。如果你对Web安全有更广泛的兴趣,希望与其他安全研究者交流,也可以访问云栈社区的安全技术板块,那里有更多相关的讨论与资源分享。
本文参考了公开技术分享:https://medium.com/@dsmodi484/finding-idor-vulnerabilities-key-endpoints-and-resources-b9b4084edf34
|