官网：http://securitytech.cc/
€2000 奖金 —— 从 IDOR 到权限提升：由管理员跃升为内部员工
大家好！ 今天，我将带你深入剖析一个因 IDOR（不安全的直接对象引用）导致的严重权限提升案例。多年经验告诉我：千万别忽视 Burp 的 HTTP 历史记录——那些看似平凡的请求和响应，往往暗藏玄机。
在一次常规侦察中，我回顾 Burp 流量，意外发现响应里出现了 "Role":"UUID" 字段。这个微小细节，最终成为我突破账户权限边界的关键。
一切始于看似正常的操作。我登录该应用的管理后台，浏览用户管理、访问控制与权限配置等常规功能，未发现异常。进入 /users 页面后，系统列出 26 位用户，覆盖三种角色：管理员、合作伙伴和普通用户。
作为管理员，我虽可更改用户角色，但界面仅提供三种选项：用户、管理员、合作伙伴。
深入检查 HTTP 历史时，我注意到一条自动触发的 GET 请求 返回了 200 OK，大致如下：
https://target.com/get/user/roles
继续实验角色切换时，我察觉一个微妙之处：当我选择 管理员或用户 时，请求体并非直接写“Admin”，而是附带一个 UUID，例如：
POST /edit/user/roles HTTP/1.1
Host: target.com
Cookie: sessionid=REDACTED
Content-Type: application/json
Content-Length: 105
{
"name":"test",
"email":"test@example.com",
"Role":"111e4567-e89b-12d3-a456-426614174000"
}
我立即将该 UUID 复制到 Burp 历史中搜索，结果在之前的 GET /user/roles 响应里找到了完全一致的值。然而，该响应并未只列出三种常见角色，而是给出了 四个 UUID：
ExampleAdmin → 111e4567-e89b-12d3-a456-426614174000
User → 222e4567-e89b-12d3-a456-426614174111
Partner → 333e4567-e89b-12d3-a456-426614174222
Role 4 → 444e4567-e89b-12d3-a456-426614174333
直觉告诉我，这第四个 UUID 绝不简单——它未在 UI 中出现，显然被刻意隐藏。于是，我决定测试它的真实身份。
我直接将这个神秘 UUID 替换到角色修改请求中，发送至服务器。结果毫无阻碍地返回 200 OK，没有任何警告或“未授权”提示。
这一简单的 UUID 替换，竟成为通往系统核心的“黄金票据”。我发现该角色对应内部员工权限，远高于管理员。
原本系统只有 26 个用户角色，在我的一番操作后，总数飙升至 40。我瞬间拥有了对 12 位内部员工 的增删改权限，而这些角色本应与我绝缘。
同时，两个“特殊”账号也浮出水面：
- System —— 仅具备查看权限
-
- Hosting —— 权限极高，且可被我任意编辑甚至删除
简言之，我的权限从普通管理员跃升为可操控内部员工及系统账号的超级用户。
这已不只是一次权限提升，更是一次横向渗透至系统核心的突破。
影响评估
CVSS-v3 评分：8.8
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- 机密性（C:H） —— 攻击者可访问仅内部高权限用户可见的敏感数据
-
- 完整性（I:H） —— 可篡改或删除内部记录，并将更高权限分配给未授权账户
-
- 可用性（A:H） —— 内部账户可被删除，造成相关资源完全不可用
-
- 所需权限（PR:L） —— 只需低权限的已登录账户即可发起攻击，随后横向提升至更高权限
