🔐 访问控制漏洞与IDOR：理解Web应用安全的隐形杀手
说实话——如今大多数成熟的Web应用都对SQL注入和XSS等经典攻击有着坚实的防御。在现代框架、WAF和自动化扫描器之间，这些漏洞越来越难发现。但访问控制漏洞？这完全是另一回事。
访问控制漏洞不是关于绕过过滤器——而是关于滑过逻辑漏洞。这种漏洞就藏在显而易见的地方：一个被遗忘的端点、一个缺失的角色检查、一个假设过多的多步骤流程。这正是它成为当今漏洞赏金计划中最常被利用和奖励最高的缺陷之一的原因。
在本文中，我将分解访问控制漏洞的真正含义，IDOR如何融入其中，并分享一些实用的技巧和测试方法，帮助你发现和利用这些漏洞——因为一旦你理解了这些漏洞的工作原理，你就会发现它们无处不在。
🧭 什么是访问控制？
访问控制是决定谁能在Web应用程序中执行什么操作的机制。它根据角色、权限或上下文，管理哪些用户可以访问特定资源、执行某些操作或查看敏感数据。
例如，它决定：
- 用户是否可以查看其他用户的个人资料
- 端点是否仅限于管理员访问
- 低权限用户是否可以执行为更高角色保留的限制功能
🔓 什么是访问控制漏洞和IDOR？
访问控制漏洞发生在应用程序未能正确强制执行用户允许执行的操作时。这不是关于绕过身份验证——而是关于执行基于你的角色或上下文应该受到限制的操作或访问数据。
这些缺陷通常在以下情况下出现：
- 角色检查缺失或薄弱
- 敏感端点在没有适当验证的情况下暴露
- 应用程序假设前端会强制执行访问规则
最常见的访问控制漏洞变体之一是IDOR——不安全的直接对象引用。当使用用户控制的参数值直接访问资源或功能，而没有验证当前用户是否有权访问引用的对象时，就会出现这种漏洞。
例如：
- 在请求中将user_id=123改为user_id=124，并获取他人的数据
这些漏洞很隐蔽。它们不会使应用程序崩溃。它们不会抛出错误。但它们会暴露敏感数据，允许权限提升，并经常导致高严重性的赏金支付。
🧪 访问控制漏洞的方法论和测试技巧
在深入访问控制漏洞测试之前，你需要正确设置心态。这不是关于抛出有效载荷——而是关于理解应用程序的逻辑、角色和流程。
首先观察你被允许做什么，什么似乎受到限制。问自己：
- 作为登录用户，我可以执行哪些操作？
- 我可以访问哪些数据？
- 什么被阻止或对我隐藏？
然后开始映射角色。例如：
- 访客：可以浏览公共页面，可能可以注册
- 用户：可以访问自己的仪表板、个人资料和基本功能
- 管理员：可以管理用户、查看敏感数据或执行系统级操作
你的目标是理解每个角色应该做什么——然后测试当你跨越这些边界时会发生什么。
🔍 侦察技巧
- 使用不同角色爬取应用程序并比较行为
- 检查你的Burp历史记录，寻找包含有用参数的端点，如： userId=, orgId=, username=, role=, accountId=等
- 检查页面源代码中隐藏的URL或端点
- 查看/robots.txt中不允许的路径——有时它们会揭示内部路由
🧨 测试技巧和有效载荷思路
头部操纵 如果你被阻止访问URL，尝试使用以下头部绕过：
|
|
或：
|
|
由于反向代理设置，某些应用程序会尊重这些头部。
URL变体 尝试不同的大小写或扩展名：
|
|
具有useSuffixPatternMatch的Spring应用程序可能将/admin.anything视为有效。
Referrer欺骗 某些应用程序检查请求是否来自内部页面。尝试：
|
|
特别是在访问敏感端点如/admin/deleteUser时。
ID操纵 如果你看到类似userId=123的内容，尝试更改它：
- 改为其他数字（124、999等）
- 改为其他用户名（Pirlo → anotherUser） 即使ID不可预测，也尝试使用来自其他账户的ID或响应中泄露的内容
角色篡改 如果你发现类似role=1的参数，尝试更改它：
|
|
有时这些值会在响应中回显——尝试将它们注入更新或登录流程
重定向泄漏 即使篡改userId会将你重定向到登录页面，也要仔细检查响应。某些应用程序在重定向过程中会泄漏数据——检查头部、正文和任何嵌入信息。
步骤跳过逻辑 某些应用程序仅在早期步骤强制执行访问控制。例如：
- 选择用户
- 确认操作
- 提交删除
如果步骤3不重新验证访问权限，你可以跳过步骤1和2，直接使用所需参数访问最终端点。
🧠 最后思考
始终记住，访问控制漏洞不是关于在任何地方使用相同的技巧——而是关于理解场景、调整你的方法，并根据应用程序暴露的内容进行测试。头部、角色篡改、步骤跳过、ID操纵——它们都依赖于上下文。你观察得越多，就能发现越多的模式。
我们已经到达本文的结尾。希望你喜欢并觉得有用❤️
欢迎在LinkedIn上与我联系。