\(A01\) \(Broken\) \(Access\) \(Control\) 访问控制失效
描述：
访问控制执行相关策略，以确保用户不会超出其预期权限进行操作。访问控制失效通常会导致未授权的信息泄露、所有数据被修改或破坏，或者用户在其权限范围外执行业务功能。
常见的访问控制漏洞：
违反最小权限原则或默认拒绝原则，即访问权限本应仅授予特定功能、角色或用户，却对任何人开放。
通过修改URL（参数篡改或强制浏览）、内部应用程序状态、HTML页面，或使用攻击工具修改API请求来绕过访问控制检查。
URL 全称 Uniform Resource Locator，意为统一资源定位符，也就是网页、图片、接口等资源在互联网上的地址，
例如：https://www.baidu.com 和 https://example.com/app/accountInfo?acct=123
一个 URL 通常由一下几个部分组成：
1. 协议：https:// 或 $http://
2. 域名（IP）：www.example.com
3. 路径：/app/accountInfo
4. 参数：?acct=123
攻击者修改 URL 里的参数或路径，就能尝试越权看别人信息、进后台
API 全称 Application Programming Interface，意为应用程序编辑接口，也就是程序和程序之间的传话通道。
通俗的讲，API 就是餐厅的服务员。你想要什么菜直接跟服务员说就可以，不需要自己跑去后厨。
例如，你打开一个 APP，点开“我的订单”，手机就调用 API 问服务器，“把这个用户的订单给我”，服务器就通过 API 把数据返回给你。
https://xxx.com/api/getUserInfo?userid=123
这是一个 API 地址，如果没校验权限，攻击者把 123 改成别人的 ID，就能看别人的信息
允许查看或编辑其他人的帐户，通过提供其唯一标识符（不安全的直接对象引用）
在 POST、PUT 和 DELETE 操作中缺少访问控制的 API
这类漏洞的核心问题是：API 仅开放了增 / 改 / 删的请求方法，却未在服务端校验调用者的权限、身份，导致攻击者可通过任意工具发起请求，实现未授权的资源创建、修改、删除
权限提升。未登录时冒充用户，或作为用户登录时冒充管理员。
元数据操纵，例如重放或篡改JSONWeb Token（JWT）访问控制令牌，或者操纵Cookie或隐藏字段以提升权限，又或者滥用JWT失效机制。
JSON Web Token（JWT） 是一种轻量级的、基于 JSON 的令牌格式，用于在网络应用间安全地传递身份验证和授权信息，也是目前前后端分离、API 接口中最常用的无状态身份认证方式
核心特点：无状态。服务端无需存储令牌，仅通过加密验证即可确认令牌有效性
JWT 的令牌是一串Base64 编码的字符串，由头部（Header）、载荷（Payload）、签名（Signature） 三部分组成，格式为：Header.Payload.Signature
例如：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE4MDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
1. 头部（Header）：声明令牌类型和加密算法
内容：JSON 格式，主要包含 2 个字段
alg：使用的签名算法（如 HS256/HMAC-SHA256、RS256/RSA-SHA256，核心是保证签名不可篡改）；
typ：令牌类型，固定为JWT；
处理：Base64 编码（可解码，非加密，任何人都能看）。
2. 载荷（Payload）：存储核心的身份 / 授权信息
内容：JSON 格式，存储用户标识、角色、权限、令牌过期时间等业务数据，分为 3 类字段：
标准注册字段（可选）：iss（签发者）、exp（过期时间，必设，核心安全字段）、sub（主题）、iat（签发时间）等；
自定义字段（业务相关）：userId（用户 ID）、role（用户角色，如 admin/normal）、scope（API 权限范围）等；
处理：Base64 编码（可解码，绝对不能存敏感数据，如密码、令牌密钥、银行卡号等）。
示例（A01 漏洞高发点：攻击者常篡改role为 admin 实现提权）
3. 签名（Signature）：JWT 的安全核心，防止令牌篡改
作用：验证令牌是否被篡改、是否由合法签发者生成，是 JWT 防篡改的唯一屏障；
生成方式：服务端使用头部声明的算法，将编码后的 Header + 编码后的 Payload拼接，再用服务端私钥 / 密钥（Secret） 进行加密，得到签名；
对称加密（HS256）：服务端唯一密钥加密，加密 / 验证用同一个密钥（简单但密钥泄露即全盘崩溃）；
非对称加密（RS256）：用私钥加密签名，公钥验证签名（更安全，适合分布式系统，私钥仅服务端持有）；
核心特性：签名不可伪造 / 篡改—— 如果 Payload 或 Header 被修改，服务端验证签名时会直接失败，令牌失效。
JWT 的工作流程：
用户登录：用户输入账号密码，服务端验证通过后，生成 JWT 令牌（按 Header+Payload+Signature 规则），并返回给前端；
前端存储：前端将 JWT 存储在localStorage/sessionStorage/cookie中（cookie 更安全，可防 XSS）；
接口请求：前端每次调用需要权限的 API 时，将 JWT 放在请求头（Authorization: Bearer <token>） 中传递给服务端；
服务端验证：服务端接收到 JWT 后，执行 3 步验证：
解码 Header，获取签名算法；
用本地密钥 / 公钥验证 Signature 的有效性（防止篡改）；
校验 Payload 中的exp（过期时间）、iss（签发者）等字段；
权限校验：验证通过后，从 Payload 中解析出userId、role等信息，执行访问控制校验（如判断是否为管理员、是否为资源所有者），校验通过则返回接口数据，否则拒绝访问（A01 漏洞常出现在这一步：跳过权限校验）。
JWT 相关的A01 访问控制失效典型安全风险：
1. 篡改 JWT 载荷实现权限提升（最典型）：攻击者解码 JWT 的 Payload，将普通用户的role: "normal"改为role: "admin"，再重新编码拼接，但未修改签名（或破解弱密钥后伪造签名），若服务端仅验证令牌存在，未验证签名 / 权限，则直接实现管理员越权（对应 A01 的 “提权漏洞”）。
2. 重放攻击：利用未过期的 JWT 冒充用户。攻击者窃取用户的有效 JWT（如通过 XSS、抓包、中间人攻击），在令牌exp过期前，直接使用该令牌调用 API 接口，若服务端未做令牌唯一标识 / 刷新机制，则攻击者可冒充用户执行操作（对应 A01 的 “未授权访问”）。
3. JWT 过期时间（exp）配置不当
场景 1：未设置exp，令牌永久有效，一旦泄露则用户身份永久被冒充；
场景 2：exp过期时间过长（如 30 天），扩大了令牌泄露后的攻击窗口；
4. 签名算法被篡改 / 禁用：攻击者将 Header 中的alg: "HS256"改为alg: "none"（无签名），若服务端未校验算法合法性，会直接跳过签名验证，接受任意篡改后的 JWT（高危漏洞，几乎等于令牌无防护）。
5. 弱密钥 / 密钥泄露：签名可被伪造
场景 1：使用简单弱密钥（如 123456、admin）进行 HS256 加密，攻击者可通过暴力破解得到密钥，进而伪造任意 JWT；
场景 2：服务端密钥泄露（如硬编码在代码、配置文件提交到 Git），攻击者直接用密钥伪造签名，篡改 Payload 后生成合法 JWT。
6. JWT 注销失效机制缺失：JWT 是无状态的，服务端未存储令牌，若用户退出登录 / 账号被冻结 / 密码修改，但已签发的 JWT 未到exp时间，令牌仍有效，攻击者可继续使用该令牌访问，导致访问控制失效（OWASP 将此列为 JWT 的核心安全缺陷）。
7. 敏感信息存储在 Payload 中：开发人员将密码、手机号、令牌密钥等敏感数据存在 Payload 中，因 Payload 仅做 Base64 编码（可直接解码），攻击者获取令牌后可直接窃取敏感信息，进而进一步发起攻击（对应 A01 的 “敏感信息泄露”）。
CORS配置错误允许来自未授权/不可信源的API访问。
CORS 全称 Cross-Origin Resource Sharing，意为跨域资源共享。
浏览器默认禁止不同域名、端口、协议的页面之间相互请求资源（如http://a.com不能请求https://b.com的 API），是浏览器的基础安全防护。CORS 的作用：由服务端通过设置 HTTP 响应头，明确告知浏览器「哪些外部域名可以访问本服务的资源」，让浏览器放行合法的跨域请求。
高发的 CORS 配置错误场景（从高危到中危排序）
场景 1：Access-Control-Allow-Origin: *（最高危，全网可访问）
配置说明：服务端直接将允许来源设为*，表示任何域名都可以跨域访问本服务的 API；
漏洞危害：攻击者可在任意恶意网站发起跨域请求，调用目标服务的敏感 API（如用户信息、数据修改），直接突破访问控制；
场景 2：未校验 Origin，动态返回请求头的 Origin 值
配置说明：服务端未做任何 Origin 白名单校验，直接将响应头的Allow-Origin设为请求头的Origin值（即「请求什么来源，就允许什么来源」）；
漏洞危害：与*等效，攻击者可构造任意恶意 Origin，服务端都会授权，导致任意域名可跨域访问 API；
场景 3：白名单配置过宽 / 正则校验宽松
配置说明：服务端虽配置了 Origin 白名单，但白名单过宽（如允许*.abc.com，但包含恶意子域名），或正则校验宽松（如匹配abc.com时未加结束符，导致abc.com.hacker.com也被允许）；
漏洞危害：攻击者可利用白名单中的宽松规则，构造符合条件的恶意域名，实现未授权跨域访问。
场景 4：允许敏感请求方法 / 头的全量授权
配置说明：服务端将Access-Control-Allow-Methods设为*，或允许PUT/DELETE/POST等高危写操作的跨域访问，且未配合其他权限校验；
漏洞危害：攻击者可在恶意网站发起跨域的 PUT/DELETE 请求，修改 / 删除目标服务的敏感数据，结合 A01 的「POST/PUT/DELETE 缺少访问控制」，漏洞危害翻倍。
CORS 配置错误的典型攻击流程（结合 A01）
受害者登录目标网站https://target.com，浏览器保存登录凭证（Cookie/JWT）；
攻击者诱导受害者访问恶意网站https://hacker.com；
恶意网站发起跨域请求到https://target.com/api/user/info，携带受害者的登录凭证；
因target.com的 CORS 配置错误（如Allow-Origin: *），服务端允许该跨域请求；
恶意网站获取受害者的个人信息，或发起跨域 PUT 请求修改受害者的信息，实现未授权访问 / 数据篡改（典型 A01 访问控制失效）。
作为未认证用户强制浏览已认证页面，或作为标准用户强制浏览特权页面。
如何预防
除公共资源外，默认拒绝。
一次性实现访问控制机制，并在整个应用程序中重复使用，包括尽量减少跨域资源共享（CORS）的使用。
模型访问控制应实施记录所有权机制，而非允许用户创建、读取、更新或删除任何记录。
模型访问控制是在应用的业务数据模型（Domain Model）层执行访问控制策略的机制，而非仅在接口、控制器等上层做校验。它将资源所有权、业务权限规则、数据操作限制直接嵌入数据模型，让所有对数据的创建、读取、更新、删除（CRUD）操作，都必须先通过模型层的权限校验，从根源上确保用户仅能操作自己有权限的资源。
简单理解：传统校验是 “门口查票”，可能漏查；模型访问控制是 “每间房间都装锁，且钥匙与房间归属严格匹配”，从源头杜绝越权。
独特的应用程序业务限制要求应由领域模型强制执行。
领域模型，就是给现实里的每样东西，定死它 “能做什么、不能做什么、谁能碰它”。
例如身份证自带规则：只有本人能用；不能借给别人犯法；过期了就无效；不能涂改信息；不能用别人的身份证办业务
这些规则不是警察临时规定的，是身份证这个东西本身就有的属性和限制。
领域模型：把规则写死在这个 “东西” 身上。谁用它，都必须遵守同一套规则。像身份证、快递一样，自带规矩，谁也改不了
禁用Web服务器目录列表，并确保文件元数据（例如.git）和备份文件不在Web根目录中。
记录访问控制失败情况，并在适当的时候（例如多次失败时）向管理员发出警报。
对API和控制器的访问进行速率限制，以最大限度地减少自动化攻击工具造成的危害。
有状态会话标识符在用户登出后应在服务器上失效。无状态JWT令牌则应设置较短的有效期，以将攻击者的可乘之机降至最低。对于有效期较长的JWT，强烈建议遵循OAuth标准来撤销访问权限。
浙公网安备 33010602011771号