OWASP Top 10 2017 A5:2017 访问控制缺陷（Broken Access Control）全面解析：漏洞原理、攻击场景与纵深防御实践

• 应用安全

导读：本文以 OWASP Top 10 官方文档仓库中 2017 年日文版 A5 章节 为主体，系统讲解"访问控制缺陷（Broken Access Control）"的风险评级、六大常见漏洞形态、八条预防措施与两个经典攻击场景。读者读完可以掌握如何识别 URL 篡改、IDOR（不安全对象直接引用）、越权、元数据篡改（JWT）、CORS 误配置与强制浏览等访问控制缺陷，并能在开发与测试环节落地"默认拒绝、服务端强制、记录所有权"等防护原则。文中结合仓库中 英文原版、发布说明、数据方法论 与 2021 版对应章节 提供源码级佐证与版本演进脉络。

一、A5:2017 概览与风险评级

在 OWASP Top 10 – 2017 中，"访问控制缺陷"位列A5，其风险评级表如下（源自 日文版原文档 与 英文版）：

| 威胁代理 / 攻击手段 | 安全弱点 | 影响 | | -- | -- | -- | | 访问级别：可利用性 2 | 蔓延度 2：可检测性 2 | 技术影响 3：业务影响因应用而定 |

风险评级依据 OWASP Risk Rating Methodology 计算，由"蔓延度、可检测性、可利用性"三个可能性要素与"技术影响"一个影响要素构成，各要素取 1（低）到 3（高）。具体计算方法可参考 风险注记 与 风险因子说明。

攻击手段层面：利用访问控制缺陷是攻击者的基础技能。静态源代码分析工具（SAST）与动态应用测试工具（DAST）只能检测访问控制的缺失，却无法验证已存在的访问控制是否真正生效。因此，访问控制缺陷的发现主要依赖人工测试，必要时可借助特定框架中对访问控制缺失的自动化检查。

弱点层面：访问控制缺陷之所以普遍，源于缺乏自动化检测以及应用开发者缺乏有效的功能测试。人工测试是发现缺失或失效访问控制的最佳途径，测试对象包括 HTTP 方法（GET 与 PUT 等）、控制器、对象直接引用等。

影响层面：技术影响表现为攻击者可以扮演普通用户、管理员或拥有特权功能的用户，或者对所有记录进行创建、访问、更新与删除；业务影响则取决于应用与数据的保护需求。

二、什么是访问控制缺陷

访问控制（Access Control）通过执行策略，确保用户不能超出其被授予的权限行事。策略执行失败通常会导致：未授权信息泄露、全部数据的修改或破坏、或执行超出用户权限范围的业务功能。

在 Top 10 全景视角下（见 2017 日语 Top 10 列表），A5 的定位是："针对仅允许授权者访问的控制未被恰当实现。攻击者可利用此类缺陷访问其他用户账户、查看机密文件、修改他人数据、变更访问权限等，进而访问未授权的功能或数据。"

值得注意的是，2017 版发布说明明确指出（见 发布说明）：

A4-不安全对象直接引用与A7-功能级访问控制缺失已被合并入A5:2017-访问控制缺陷。

这意味着 A5 是一个聚合性类别：既涵盖"对象级授权"（IDOR），也涵盖"功能级授权"（越权调用管理功能），是 2017 版对访问控制问题的一次重新梳理。

三、漏洞发现要点：六大常见访问控制缺陷

根据原文档 脆弱性发现要点，常见的访问控制漏洞包括以下六类：

1. 绕过访问控制检查

通过修改 URL、内部应用状态或 HTML 页面，或直接使用自定义 API 攻击工具，绕过访问控制检查。这类攻击不需要高超技巧，改一个参数即可完成。

2. 主键篡改导致的对象直接引用（IDOR）

允许修改主键为其他用户的记录，从而查看或编辑他人的账户。这是 2017 年数据征集调查中排名第 4 的"用户可控键授权绕过"（CWE-639）在 A5 中的体现（详见 数据方法论）。

3. 权限提升（Elevation of Privilege）

包括未登录即冒充用户行事，或以普通用户身份登录后执行管理员操作。这是访问控制失效最严重的后果之一。

4. 元数据篡改

对 JSON Web Token（JWT）访问控制令牌、Cookie 或隐藏字段进行重放或篡改以提升权限，或滥用 JWT 失效机制。例如攻击者将 Cookie 中角色字段从user改为admin。

5. CORS 误配置

CORS 错误配置导致未授权 API 访问。若服务器信任了攻击者控制的来源，跨域请求即可携带合法凭据访问受保护 API。

6. 强制浏览（Force Browsing）

未认证用户可强制浏览需认证页面，普通用户可强制浏览需特权页面；同时可访问对 POST、PUT、DELETE 方法缺少访问控制的 API。

以上六类问题与 2021 版 A01:2021-Broken Access Control 的描述高度一致（见 2021 版英文文档），后者还补充了"违反最小权限原则/默认拒绝"这一形态——访问本应仅授予特定能力、角色或用户的资源，却对任何人开放。

四、防止方法：八条纵深防御措施

原文档 防止方法 给出了八条核心预防措施。前提是：访问控制只有在受信任的服务器端代码或无服务器 API 中强制执行时才有效——攻击者无法修改访问控制检查逻辑或元数据。

1. 默认拒绝（Deny by default）：除公开资源外，一律默认拒绝访问。这条原则是访问控制的第一道闸门。

2. 一次实现、全局复用：将访问控制机制实现一次并在整个应用中复用，同时尽量减少 CORS 的使用。集中式实现可避免各模块各自为政导致的遗漏。

3. 记录所有权模型：访问控制模型应强制记录所有权，而不是允许用户创建、读取、更新或删除任意记录。即：只有记录的所有者（或获得授权的角色）才能操作该记录。

4. 业务约束落到领域模型：应用独有的业务限制需求必须在**领域模型（Domain Model）**中表达，而不能仅依赖表现层的临时检查。

5. 关闭目录列举、清理敏感文件：禁用 Web 服务器的目录列表，并确保 Web 根目录下不存在文件元数据（如.git）和备份文件。

6. 记录失败并告警：对访问控制失败进行日志记录，在适当时（如反复失败）提醒管理员。

7. 限流：对 API 和控制器实施速率限制，将自动化攻击工具的危害降到最低。

8. JWT 服务端失效：JWT 令牌在登出后应在服务器端失效，避免令牌被重放滥用。

此外，原文档强调：开发人员与 QA 人员应纳入访问控制相关的功能单元测试与集成测试。

五、攻击场景示例

原文档提供了两个经典攻击场景，均沿用至 2021 版文档（对比见 2021 版 Attack Scenarios）。

场景 #1：对象直接引用导致账户越权访问

应用在访问账户信息的 SQL 调用中使用了未经验证的数据：

pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery();

攻击者只需在浏览器中修改acct参数为任意账户编号并发送请求：

http://example.com/app/accountInfo?acct=notmyacct

若缺少适当的验证（此处指授权验证，而非仅输入格式验证），攻击者即可访问任意用户的账户信息。这正是 CWE-639（通过用户可控键绕过授权）与 CWE-566（通过用户可控 SQL 主键绕过授权）的典型形态。

场景 #2：强制浏览管理功能

攻击者直接在浏览器中访问目标 URL，其中管理员页面要求管理员权限：

http://example.com/app/getappInfo http://example.com/app/admin_getappInfo

如果未认证用户可以访问上述任一页面，即为缺陷；如果非管理员可以访问管理员页面，同样属于缺陷。这一场景对应 CWE-425（直接请求 / 强制浏览）与功能级访问控制缺失。

六、与 CWE 的映射关系

A5:2017 原文档在参考资料中映射了以下 CWE（见 原文档参考资料）：

| CWE 编号 | 名称 | | -- | -- | | CWE-22 | 受限目录路径名限制不当（路径遍历） | | CWE-284 | 访问控制不当（授权） | | CWE-285 | 授权不当 | | CWE-639 | 通过用户可控键绕过授权 |

到 2021 版，A01:2021-Broken Access Control 的 CWE 映射已扩展到34 个（见 2021 版 CWE 列表），包括 CWE-200（向未授权参与者泄露敏感信息）、CWE-352（CSRF）、CWE-425（强制浏览）、CWE-548（目录列举信息泄露）、CWE-862（缺失授权）、CWE-863（错误授权）等，可帮助读者构建更完整的授权缺陷知识图谱。

七、数据与方法论背景：为何 A5 处于第 5 位

根据 2017 数据方法论：

• 2017 版进行了社区调查（2017 年 8 月 2 日～9 月 18 日，收到 516 份回答），其中"通过用户可控键绕过授权（IDOR 与路径遍历）"（CWE-639）以 493 分排名第 4。
• 调查中虽有意见认为该类别应排名更高，但由于与授权脆弱性相关的数据不足，最终将其定位为A5:2017-访问控制缺陷，并纳入 A5 类别。
• 2017 版数据征集（CFD）覆盖了23 个贡献者、114,000 个以上应用的数据，用于计算各脆弱性的发生率排名。

这解释了 A5 评级中"蔓延度 2"的来源——访问控制问题广泛存在，但当时缺乏足够的自动化检测数据支撑更高排名。

八、版本演进：从合并到登顶（2013 → 2017 → 2021）

访问控制缺陷在 OWASP Top 10 中的地位经历了显著演变：

| 版本 | 位置 | 变化 | | -- | -- | -- | | 2013 | A4（不安全对象直接引用）+ A7（功能级访问控制缺失） | 两个独立类别 | | 2017 | A5（访问控制缺陷） | 上述两类合并为 A5 | | 2021 | A01（Broken Access Control） |跃升至第 1 位|

2021 版数据（见 A01:2021 概览）显示：约94% 的应用接受了某种形式的访问控制缺陷测试，平均发生率3.81%，在贡献数据集中出现次数最多（超过 318,000 次），共映射34 个 CWE、19,013 个相关 CVE。

从"合并归类"到"登顶榜首"的历程，说明访问控制缺陷是 Web 应用安全中最普遍、最难以自动化检测、且业务影响最直接的弱点类别之一。

九、在项目仓库中继续深入

本文涉及的相关资料均可在此仓库中查阅原文：

• 关联文档主体：2017 日文版 A5 章节、2017 英文版 A5 章节
• Top 10 全景列表：2017 日语 T10 列表
• 版本演进说明：2017 发布说明（A4/A7 合并为 A5 的依据）
• 风险评级方法论：风险注记、风险因子
• 数据来源与调查：数据方法论
• 2021 版对照：A01:2021-Broken Access Control（英文）（另有日文版等 15 种语言译本，见 2021/docs 目录）
• 2017 版官方交付物：OWASP Top 10-2017(ja).pdf.pdf)、OWASP-Top-10-2017-en.pdf、OWASP Top 10-2017 (en).pdf.pdf)

十、结语

访问控制缺陷的根源在于信任了不该信任的对象：信任了客户端可篡改的参数、令牌与元数据，信任了"没人会猜到那个 URL"。OWASP Top 10 2017 给出的答案清晰而朴素——默认拒绝、服务端强制、一次实现全局复用、强制记录所有权、关闭目录列举、记录与限流，并通过单元测试与集成测试将授权逻辑固化进工程质量。随着 2021 版将 Broken Access Control 推上榜首，这一主题在应用安全体系中的地位已无可争议；而本文所梳理的六类漏洞形态与八条防御措施，正是应对这一榜首风险最实用的行动清单。

• 应用安全