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)