26访问控制

## 概述

**访问控制**，又称**授权（Authorization）**，是安全模型中的一个过程，**访问控制依赖于身份验证和会话管理**，负责决定**“已认证的用户有权做什么”**。。

- **身份验证：**确认用户是授权用户；
- **会话管理：**识别同一用户发出的后续 HTTP 请求；
- **访问控制：**决定用户是否有权执行相关操作。

**核心问题：用户A是否可以执行操作B或访问资源C？**

- **认证**：出示你的公司门禁卡，证明你是员工（身份验证）。
- **授权**：你的门禁卡权限决定了你能进入办公楼、某个特定的实验室还是仅能进入食堂（权限验证）。

访问控制模型通常基于三种核心概念：

1. **主体（Subject）**：发出访问请求的实体（通常是用户或服务账户）；
2. **客体（Object）**：被访问的资源（如文件、数据库记录、API端点、管理功能）；
3. **操作（Operation）**：主体试图对客体执行的动作（如读、写、删除、执行）。

## 模型

主要有三种经典的模型：

**1. 自主访问控制（DAC - Discretionary Access Control）**

资源的所有者可以自主决定将访问权限授予给其他用户。

**示例**：Unix/Linux文件系统中的权限（`rwx` for user, group, others），文件所有者可以运行 `chmod` 命令来更改权限。

**2. 强制访问控制（MAC - Mandatory Access Control）**

访问策略由中央权威（如管理员）强制决定，用户和资源所有者不能自行更改，通常用于军事、政府等高安全环境。

**示例**：SELinux, AppArmor。给主体和客体打上“安全标签”（如“机密”、“绝密”），只有主体标签 dominance 客体标签时才能访问。

**3. 基于角色的访问控制（RBAC - Role-Based Access Control）**

**现代Web应用中最常见的模型**，权限不直接分配给用户，而是分配给**角色**，用户再被赋予一个或多个角色。

**示例**：

- 角色：`管理员`、`普通用户`、`财务专员`。
- 权限：`删除用户`权限分配给`管理员`角色。
- 用户：Alice被赋予`管理员`角色，因此她拥有`删除用户`的权限。

**4. 基于属性的访问控制（ABAC - Attribute-Based Access Control）**

一种更动态、更细粒度的模型，访问决策基于主体、客体、操作**属性**以及环境条件。

**属性示例**：

- 主体属性：部门、安全等级、国籍。
- 客体属性：创建日期、分类级别、所有者。
- 环境属性：时间（是否在工作时间？）、IP地址（是否在公司内网？）、设备安全状态。

**策略示例**：

- “允许`项目经理`（角色）在`工作时间`（环境）访问其`所属项目`（客体属性）的文档。”

**5. 其他扩展模型**

- **基于策略的访问控制（PBAC）**：将 ABAC 的 “属性规则” 抽象为可配置的策略模板，降低维护成本；
- **零信任访问控制（Zero Trust）**：基于 “永不信任，始终验证” 原则，即使在内部网络，也需持续验证主体身份、设备安全状态等（如每次访问都需 MFA 二次认证），是当前网络安全的主流趋势。

## 访问控制漏洞

当访问控制机制存在缺陷或缺失时，就会产生漏洞，导致**权限提升（Privilege Escalation）**。主要分为两类：

**1. 垂直权限提升（Vertical Privilege Escalation）**

一个低权限用户获得了高权限用户的权限和功能。

**示例**：

- 一个普通用户通过直接访问 `/admin/delete-user.php` URL，成功执行了管理员的功能。
- 普通用户通过修改参数，将自己的用户类型从 `user` 改为 `admin`。

**2. 水平权限提升（Horizontal Privilege Escalation）**

一个用户访问到了与他拥有**相同权限级别**的另一个用户的资源。

**示例**：

- 用户A通过将URL中的参数从 `user_id=1001`（自己的ID）改为 `user_id=1002`，成功看到了用户B的隐私信息、订单记录或个人资料。
- 这是**最常见**的访问控制漏洞。

**3. 上下文相关的权限提升（Context-Dependent Privilege Escalation）**

这与业务流程的状态有关。

**示例**：在购物流程中，用户已经“确认下单”并进入了“支付”环节，但通过浏览器回退按钮或修改URL，又返回到“修改收货地址”的步骤并进行修改。

## 测试方法

检测主要依靠**手动测试**，因为自动化工具很难理解业务的权限逻辑。

**权限映射**：

- 使用两个不同权限的账户（如 `admin` 和 `user`）访问应用。
- 记录每个账户能访问的所有URL、功能和API请求。
- 对比两个账户的访问记录，尝试用低权限账户去请求高权限账户的专属功能。

**测试IDOR**：

- 登录后，观察所有请求中的标识符（ID、用户名、邮箱）。
- 修改这些标识符，尝试访问其他用户的资源。
- 使用工具（Burp Suite）的参数爆破功能，尝试遍历ID值。

**测试元数据操纵**：

- 在请求中寻找如 `role=user`, `isAdmin=false` 等参数，尝试修改它们，观察权限是否变化。

**测试API端点**：

- 对所有API端点进行全面的权限测试，确保每个端点都进行了授权检查，而不仅仅是Web界面。

**测试直接引用**：尝试直接通过URL访问需要权限的页面或功能。

## 防护措施

防御的核心是：**除非显式允许，否则默认拒绝（Default Deny）**，并在**服务端**执行检查。

**强制实施授权检查**：

- **最重要的是：在所有受保护的端点和服务器的业务逻辑中，强制执行授权检查**。不要依赖前端隐藏按钮或菜单来提供安全。

**使用单一的、强大的访问控制机制**：

- 在整个应用程序中重用同一个授权检查模块，避免代码重复和遗漏。例如，创建一个 `isAuthorized(user, resource, action)` 函数。

**基于记录的所有权进行校验**：

- 防止水平权限提升的最有效方法。在查询数据库时，**始终将当前登录用户的ID（从Session中获取）作为查询条件的一部分**。

**采用最小权限原则**：

- 只授予用户执行其任务所必需的最小权限。不要给普通用户分配任何管理员权限。

**禁用不必要的服务器目录列表**：

- 防止攻击者通过目录遍历轻松发现可访问的资源。

## 实验

靶机地址：https://portswigger.net/web-security/access-control/lab-unprotected-admin-functionality

任务：删除用户carlos。

1、访问靶机，类似于购物网站。

![image-20250909233308061](https://oss.maolin101.com/image-20250909233308061.png-101.webp)

2、寻找robots.txt文件，发现存在管理员面板路径。

robots.txt 是一个位于网站根目录（即 `https://example.com/robots.txt`）的文本文件。

它遵循**机器人排除协议（Robots Exclusion Protocol）**，用于指示网络爬虫（如搜索引擎的蜘蛛）网站的那些部分可以被抓取，哪些部分应该被避免访问（君子协议）。

![image-20250909233402558](https://oss.maolin101.com/image-20250909233402558.png-101.webp)

3、访问，直接点击删除。

![image-20250909233424317](https://oss.maolin101.com/image-20250909233424317.png-101.webp)

4、删除成功。

![image-20250909233438046](https://oss.maolin101.com/image-20250909233438046.png-101.webp)