如何应对Access Control漏洞

访问控制（Access Control）漏洞是 Web 安全中最常见、危害也最大的问题之一（OWASP Top 10 长期位居前列）。核心原则是：确保“主体（用户/系统）只能访问其被授权的资源”。

下面从原理、常见类型、检测方式、防御措施、最佳实践几个方面系统说明如何应对。

一、访问控制漏洞的本质

访问控制漏洞的本质是：

系统未能正确校验“谁（Who）能做什么（What）、访问哪些资源（Which）”

常见表现：

• 普通用户访问管理员接口
• 用户 A 访问用户 B 的私人数据
• 绕过前端限制直接调用后端接口
• 水平 / 垂直越权

二、常见访问控制漏洞类型

1. 垂直越权（Vertical Privilege Escalation）

低权限用户访问高权限功能。

示例

GET /admin/users HTTP/1.1

普通用户访问管理员接口，后端未校验角色。

2. 水平越权（Horizontal Privilege Escalation）

同权限用户访问其他用户的数据。

示例

GET /api/orders/1001

用户 A 把 1001 改成 1002，看到用户 B 的订单。

3. IDOR（不安全的直接对象引用）

通过可预测的资源 ID 直接访问对象。

示例

GET /api/user?userId=123

4. 缺失功能级访问控制

仅在前端隐藏功能，后端未校验。

示例

• 前端隐藏“删除用户”按钮
• 后端仍接受 POST /api/admin/deleteUser

5. 上下文/业务流绕过

绕过业务流程顺序。

示例

• 未付款直接访问“已支付成功”页面
• 跳过验证码直接提交表单

三、如何检测访问控制漏洞

1. 手工测试

• 登录不同账号对比接口
• 修改 URL / 参数 ID
• 删除 / 篡改 Token / Cookie
• 重放请求（Burp Suite）

2. 自动化工具

• Burp Suite（Repeater、AuthZ、AuthMatrix）
• OWASP ZAP
• Postman + 脚本

3. 代码审计重点

• 是否每个接口都有鉴权
• 是否校验资源归属
• 是否依赖前端控制权限
• 是否使用可预测的 ID

四、防御访问控制漏洞的核心措施

✅ 1. 服务端强制校验（最重要）

永远不要信任前端

✅ 后端校验
❌ 前端隐藏按钮 / JS 判断

✅ 2. 角色 + 资源双重校验

if user.role != ADMIN:
    deny

if order.ownerId != user.id:
    deny

✅ 3. 使用间接引用（避免 IDOR）

❌ 直接暴露 DB ID
✅ 使用映射 token

order_id → uuid

或

user_id → session 中存储

✅ 4. 统一访问控制逻辑

• 中间件 / 过滤器
• 注解（如 @PreAuthorize）
• API Gateway 统一鉴权

✅ 避免每个接口重复、遗漏

✅ 5. 最小权限原则（Least Privilege）

• 默认拒绝
• 按需授权
• 管理员也分权限粒度

✅ 6. 防止参数篡改

• 签名参数
• Token 绑定资源
• 校验 Referer / Origin（辅助）

五、典型安全设计示例

✅ RESTful API 正确做法

GET /api/users/me/orders/{orderId}

而不是：

GET /api/orders/{orderId}

✅ 后端校验示例（伪代码）

if (!order.getUserId().equals(currentUser.getId())) {
    throw new ForbiddenException();
}

六、常见错误总结（一定要避免）

七、企业级最佳实践

• ✅ 使用 RBAC / ABAC
• ✅ 所有接口默认拒绝访问
• ✅ 鉴权逻辑集中管理
• ✅ 关键操作记录审计日志
• ✅ 定期做越权测试

八、总结一句话

访问控制漏洞不是“有没有登录”的问题，而是“登录后还能做什么”的问题。

如果你愿意，我也可以：

• 结合 Java / Spring / Node / Go 给你具体代码示例
• 帮你 审计一个真实接口是否存在越权风险
• 给你一份 访问控制安全 Checklist（开发/测试用）

告诉我你的技术栈即可。