企业官网建设流程全解析

• 应用安全

本文以 2017/ro/0xa5-broken-access-control.md（罗马尼亚语版，与英文版内容一致）为核心骨架，结合 OWASP Top 10 2017 官方仓库的完整文档体系，系统讲解 A5:2017 越权访问控制的威胁画像、脆弱性判定、攻击场景与纵深防御方案。读完本文，你将掌握：如何识别应用中的访问控制缺陷（IDOR、越权浏览、CORS 误配置等）、如何落地"默认拒绝 + 服务端强制 + 记录所有"的访问控制策略，以及如何通过单元/集成测试与日志监控形成闭环。

一、风险定位：A5:2017 在 Top 10 中的坐标

OWASP Top 10 2017 将"访问控制"列为A5:2017-Broken Access Control，其官方定义（见 0x11-t10.md）为：

对已认证用户允许执行操作的约束常常未被正确执行。攻击者可利用这些缺陷访问未授权的功能或数据，例如访问其他用户账户、查看敏感文件、修改他人数据、变更访问权限等。

值得注意的是，A5:2017 并非全新类别，而是由 2013 版中的两个独立类别合并而来。根据 0x06-release-notes.md 的发布说明：

A4-Insecure Direct Object References（不安全直接对象引用）与A7-Missing Function Level Access Control（缺失功能级访问控制）合并为A5:2017-Broken Access Control。

这一合并反映出业界共识：对象级越权（IDOR）与功能级越权本质上是同一类问题——"对资源与功能的访问约束未被正确执行"。在 2017 年数据征集中，社区调查将CWE-639（通过用户可控键绕过授权，含 IDOR 与路径遍历）列为第四高优先级类别，并最终纳入 A5（见 0xd0-about-data.md）。

二、威胁画像与风险评级

A5:2017 的风险评级表（源自关联文档首部的威胁/弱点/影响矩阵）如下：

| 威胁代理/攻击向量 | 安全弱点 | 影响 | | -- | -- | -- | | 可利用性：2（平均） | 普遍性：2（常见）；可检测性：2（平均） | 技术影响：3（严重）；业务影响：视应用与数据保护需求而定 |

威胁代理与攻击向量：利用访问控制缺陷是攻击者的核心技能。SAST（静态应用安全测试）与 DAST（动态应用安全测试）工具能检测"访问控制缺失"，却无法验证"已存在的访问控制是否真正生效"。因此，访问控制的可检测性天然偏弱——最可靠的方式是人工测试，辅以对特定框架中访问控制缺失的自动化检测。

安全弱点：由于缺少自动化检测手段，且应用开发者普遍缺乏有效的功能测试，访问控制弱点非常普遍。人工测试是发现缺失或失效访问控制的最佳方式，检测点包括 HTTP 方法（GET 与 PUT 等）、控制器、直接对象引用等。

影响：技术层面，攻击者可扮演普通用户或管理员、使用特权功能、创建/访问/更新/删除任意记录；业务层面，影响取决于应用与数据的保护需求。

关于该风险评级方法的推导过程（普遍性、可检测性、可利用性三个似然因子 × 技术影响因子），可进一步阅读 0x10-app-security-risks.md 与 0xc0-note-about-risks.md。

三、如何判定应用是否存在访问控制缺陷（Is the Application Vulnerable?）

访问控制的本质是强制执行策略，使用户无法越出预期权限行事。一旦失效，通常导致未授权信息泄露、全部数据的修改或破坏，或执行业务边界之外的业务功能。关联文档列出的常见访问控制漏洞包括：

1. 绕过访问控制检查：通过修改 URL、内部应用状态或 HTML 页面绕过校验，或直接使用自定义 API 攻击工具。
2. 篡改主键（IDOR）：允许将主键改为他人的记录，从而查看或编辑他人账户。
3. 权限提升：未登录即以用户身份操作，或以普通用户身份执行管理员操作。
4. 元数据操纵：重放或篡改 JSON Web Token（JWT）访问控制令牌；篡改 Cookie 或隐藏字段以提升权限；滥用 JWT 失效机制。
5. CORS 误配置：允许未授权的 API 跨域访问。
6. 强制浏览（Force Browsing）：未认证用户访问需认证的页面，或普通用户访问特权页面；访问缺少 POST、PUT、DELETE 访问控制的 API。

判定要点：凡是"客户端可控的数据被直接用于决定访问权限、且服务端未做二次校验"的场景，都应当视为存在缺陷。例如通过修改 URL 参数、请求方法或请求头即可访问他人数据或特权功能，即判定为脆弱。

四、如何防御：九条访问控制最佳实践（How To Prevent）

关联文档强调一个总原则：访问控制只有部署在可信的服务端代码或无服务器 API 中才有效——在那里，攻击者无法篡改访问控制检查或元数据。在此基础上，官方给出九条可落地的预防措施：

1. 默认拒绝（Deny by Default）：除公开资源外，一律默认拒绝访问。
2. 访问控制机制一次实现、全应用复用：避免各模块各自实现一套校验逻辑，并尽量减少 CORS 的使用面。
3. 模型层强制记录所有权（Record Ownership）：访问控制应校验"该记录属于当前用户"，而不是无条件接受用户对任意记录的增删改查。
4. 业务限额由领域模型强制执行：应用特有的业务限制（如配额、频率）应由领域模型把关，而非依赖前端。
5. 禁用 Web 服务器目录列举：确保 .git 等文件元数据与备份文件不暴露在 Web 根目录下。
6. 记录访问控制失败事件：对重复失败等异常及时告警管理员。
7. 对 API 与控制器实施限流（Rate Limit）：降低自动化攻击工具的破坏力。
8. JWT 登出后服务端失效：防止令牌被重放复用。
9. 开发者与 QA 编写功能级访问控制单元测试与集成测试：把"校验是否生效"纳入自动化测试，弥补人工测试的覆盖面缺口。

这九条措施覆盖了"架构（1-4）、部署（5）、监测（6-7）、令牌生命周期（8）、质量保障（9）"五个层面，构成了访问控制的纵深防线。

五、典型攻击场景（Example Attack Scenarios）

场景一：对象级越权（IDOR）——篡改账户参数

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

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

攻击者只需在浏览器中修改acct参数，即可传入任意账户号。若未正确校验，攻击者便能访问任何用户的账户：

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

该场景对应 CWE-639（通过用户可控键绕过授权），也是 A5 合并 IDOR 类别的典型体现。防御要点即上文第 3 条——模型层必须校验记录所有权，而不能信任客户端传入的acct键。

场景二：功能级越权——强制浏览特权页面

攻击者直接强制浏览目标 URL，例如：

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

若未认证用户可访问其中任一页面，即为缺陷；若非管理员可访问管理员页面，同样属于缺陷。此场景对应合并前的 A7-Missing Function Level Access Control，防御要点是"默认拒绝 + 服务端功能级授权校验"。

场景三：方法级越权（推断补充）

除上述两个官方场景外，关联文档在"脆弱性判定"中明确提示：访问控制缺失还常见于 API 的 POST、PUT、DELETE 方法。攻击者通过切换 HTTP 方法即可触发本应禁止的写操作——例如将GET /api/user/123改为DELETE /api/user/123，若服务端未按方法实施授权校验，即可实现越权删除。此类缺陷可结合人工测试（逐一尝试各 HTTP 方法与控制器组合）发现。

六、仓库中的延伸证据与实践配套

OWASP Top 10 2017 仓库围绕 A5 及整套 Top 10 提供了完整的配套资料，可作为深入学习的入口：

• 英文权威版：2017/en/0xa5-broken-access-control.md（本文关联文档的英文原版，罗马尼亚语版 2017/ro/0xa5-broken-access-control.md 内容与之完全一致，另有 es/fa/fr/he/id/ja/pt-br/pt-pt/ru/tr 等多语言版本）。
• 风险评级方法：0x10-app-security-risks.md 定义了威胁代理/可利用性/普遍性/可检测性/技术影响的五维评级表；0xc0-note-about-risks.md 详细解释了"似然 × 影响"的计算方法及其局限。
• 2017 版变化：0x06-release-notes.md 记录了 A4+A7 合并为 A5 的来龙去脉，以及微服务、SPA、Node.js 等架构变迁对访问控制假设的冲击。
• 数据方法论：0xd0-about-data.md 说明 A5 相关数据来自 23 个贡献方、约 114,000 个应用的统计，以及社区调查中 CWE-639 位列第四的实证背景；原始数据与提交模板位于 2017/datacall/submissions/，分析结果见 2017/datacall/analysis/。
• 2021 演进：A5 在 2021 版中进一步跃升至首位 A01:2021-Broken Access Control（见 2021/docs/en/），侧面印证了访问控制问题在真实世界的持续高发。

七、参考条目（关联文档 References 部分的本地化呈现）

关联文档的 References 包含 OWASP 与外部两类资料。外部链接（OWASP Wiki、CWE、PortSwigger 等）不在此处重复给出网址，其核心检索词如下，可在 OWASP 官网及 CWE 数据库中查询原文：

OWASP 系：OWASP Proactive Controls（访问控制条目）、OWASP Application Security Verification Standard（ASVS V4 访问控制）、OWASP Testing Guide（授权测试）、OWASP Access Control Cheat Sheet。

外部系：CWE-22（路径遍历）、CWE-284（不正确的访问控制/授权）、CWE-285（不正确的授权）、CWE-639（通过用户可控键绕过授权）、PortSwigger 的 CORS 误配置利用研究。

其中CWE-639与 A5 关联最为紧密——社区调查将其单独列出并高票纳入 A5，说明"用户可控键绕过授权"是访问控制缺陷中最具代表性的子类型，也是本文场景一（IDOR）的标准映射。

八、结语：把访问控制当作"默认拒绝的系统约束"

A5:2017 的核心教训可以浓缩为一句话：不要在客户端做访问控制，不要在业务代码里"顺便"做访问控制。正确的姿势是——在可信的服务端边界统一实现授权检查，默认拒绝一切非公开访问；模型层强制记录所有权；对每个 API 方法与控制器做功能级校验；配合限流、失败日志与告警、JWT 服务端失效，并用单元/集成测试把"校验已生效"固化为可回归的工程质量。唯有如此，才能将 A5 从"高危榜单条目"转化为可度量、可验证的工程实践。

延伸阅读：完整 Top 10 风险列表见 2017/en/0x11-t10.md；2017 版官方最终文档（PDF/PPTX/HTML）见 2017/README.md；历年版本对比见 2021-2003_Comparison/。

• 应用安全