身份授权与隐私测试

• Authorization Code Flow 的流程
• state 参数防 CSRF 的验证
• PKCE 的 code_challenge 与 code_verifier

OAuth 2.0 授权码模式（Authorization Code Flow）是 Web 应用最安全的授权流程：用户授权后，授权服务器返回 code，客户端用 code 换取 access token。测试要点：验证授权请求是否带上随机 state 参数，服务端在回调时校验 state 是否与发起时一致，从而防 CSRF（防止攻击者诱导用户授权后把 code 劫持）；验证 code 是否一次性使用、有时效、且绑定到客户端（客户端凭证校验）。PKCE（Proof Key for Code Exchange）用于提升授权码安全性，尤其适合移动端/SPA：客户端生成随机 code_verifier，派生 code_challenge 随授权请求发送，换取 token 时需提交 code_verifier，服务端校验其与 code_challenge 是否匹配，从而防止授权码被拦截后用于换取 token。测试应验证 code_challenge 的生成、code_verifier 的校验、以及 state 校验是否真实生效。

授权码 + PKCE 是防code劫持与CSRF的现代标准。测试应验证 state 与 code_challenge 的校验逻辑，而非仅看流程是否走通。

• alg=none 攻击的测试
• kid 注入攻击的测试
• 算法混淆（RS/HS 混淆）攻击

JWT 易受三类攻击：alg=none 攻击，攻击者将头部 alg 改为 none 并去签名，若服务端信任该算法则绕过验证，测试应构造 alg=none 的 token 验证是否被拒绝；kid 注入攻击，kid 是头部中的密钥标识，攻击者将 kid 设为可控值（如 SQL 注入路径、../../ 指向任意文件、可控参数）以诱导服务端用错误密钥验证，测试应验证 kid 是否被白名单/路径校验约束；算法混淆攻击（Algorithm Confusion），攻击者把 RS256（非对称）改为 HS256（对称），诱导服务端用公钥作为 HMAC 密钥验证，测试应构造 RS256 签名但声明 HS256 的 token 验证是否被拒绝。防护验证：确认 JWT 库配置了算法白名单（仅允许预期算法）、显式校验签名且不信任客户端指定的算法、kid 经过严格校验。测试应确认这些防护配置真实生效。

三类攻击都源于"信任客户端提供的算法/标识"。测试应构造相应的畸形 token，验证服务端是否严格校验算法、签名与 kid，而非仅依赖库默认行为。

• ID Token 与 Access Token 的用途差异
• nonce 防重放验证
• aud 受众验证

OIDC 中 ID Token 是 JWT，用于向客户端确认用户身份（携带用户信息、exp、aud、iss、nonce），由客户端本地验证；Access Token 用于访问资源服务器，由资源服务器验证，OIDC 下多为不透明 token。验证差异：ID Token 需客户端校验签名、iss（签发者）、aud（受众）、exp（过期）与 nonce；Access Token 由资源服务器校验作用域与权限。测试要点：nonce 防重放，客户端在授权请求中生成随机 nonce，验证 ID Token 中的 nonce 与发起时一致，防止重放冒用，测试应验证 nonce 校验是否生效；aud 受众验证，ID Token 的 aud 必须等于客户端 ID，防止 token 被其他客户端冒用，测试应验证错误的 aud 是否被拒绝；iss 签发者验证，ID Token 的 iss 必须等于可信签发者，测试应验证伪造的 iss 是否被拒绝。三者缺一不可，共同防止身份冒用与重放。

ID Token 与 Access Token 的关注点不同：前者验身份（nonce/aud/iss），后者验权限（scope）。测试应分别验证 ID Token 的 nonce、aud、iss 校验与 Access Token 的作用域校验。

• JWT 密钥泄露的检测方法
• 密钥轮换（rotation）的机制
• 新旧 Token 的兼容处理

JWT 密钥泄露危害大，需检测与轮换。检测：扫描代码/配置/仓库历史中的硬编码密钥、监控密钥的异常使用（如签名 token 的异常来源）、对比公钥指纹，识别是否泄露。轮换（rotation）：定期或发现泄露后更换签名密钥，为保证平滑，采用"双密钥并存"——新钥签发新 token，旧钥保留一段缓存期仍可验证旧 token，避免已签发的 token 立即失效导致用户中断。兼容处理测试：验证轮换后，用新钥签发的 token 能通过验证、在缓存期内的旧钥 token 仍有效、缓存期结束后旧 token 被拒绝；验证配置的 kid 标识能正确区分新旧密钥。测试还应覆盖：轮换后所有服务端一致更新、签名/验证对称、无硬编码密钥残留、以及泄露时能即时撤销（改用黑名单拒绝）。完整测试确保轮换"平滑、安全、可回滚"。

密钥轮换的核心是"平滑过渡"。测试应验证新旧密钥并存期与切换后的兼容，确保轮换不中断用户且安全过渡。

• RBAC 角色继承的测试
• 互斥约束（SoD）的测试
• 水平越权（IDOR）测试

RBAC 测试覆盖角色建模与权限决策。角色继承：验证子角色是否继承父角色权限、权限覆盖是否按预期、越权赋权是否被禁止，测试用各角色实访资源核对权限矩阵。互斥约束（SoD）：验证同一用户不能同时拥有互斥角色（如"申请者"与"审批者"），某角色被赋权/被撤权后的权限即时生效，测试用同一账号尝试操作用互斥角色才能执行的动作是否被拒。越权测试分为：水平越权（IDOR），攻击者访问同级别其他用户的资源，测试通过修改资源 ID（主键）访问他人数据，验证是否按用户身份校验所有权；垂直越权（权限提升），低权限用户访问高权限功能，测试用低权限账号直接访问高权限接口/入口，验证服务端是否强制校验角色。系统化方法：对每个资源点做"正/反"测试，用不同角色矩阵逐一验证，并结合权限矩阵与用例生成器覆盖。

RBAC 与越权测试的核心是"以用户身份验证权限决策"。测试应覆盖角色矩阵、互斥约束与水平/垂直越权，验证服务端强制校验而非仅前端隐藏。

• 访问权、删除权、可携带权的验证
• 被遗忘权在主数据中生效
• 备份、日志与第三方数据的删除

GDPR 数据主体权利测试需覆盖三类：访问权，验证用户能请求并获取其个人数据的副本，且返回完整、格式正确；删除权（被遗忘权），验证用户请求删除后，其数据从主数据库中移除，且无法再访问；可携带权，验证用户能以结构化、机器可读格式导出其数据。关键难点是"被遗忘权"的扩散：删除不仅限于主数据，还需确认备份数据在留存周期到期后被清除、日志中的个人数据被脱敏或删除、以及第三方（数据分析、支付、营销等）共享的数据被同步删除或无法再关联主体。测试应验证：删除请求后主库、缓存、备份、日志、第三方接口的数据均不再可用，并核对数据留存策略与删除调度是否执行。完整验证第三方与备份的"扩散删除"才能满足合规。

被遗忘权测试的难点在于"数据扩散"。测试者应追踪数据流的每个落脚点（主库、备份、日志、第三方），验证删除请求的全面生效。

• ABAC 属性模型的组合爆炸
• Pairwise/组合测试方法
• 组合降维与约束处理

ABAC 基于主体、资源、环境、操作等多属性组合做权限决策，属性组合会产生组合爆炸（如 6 个属性各 3 值 = 729 种组合）。缓解方法：用 Pairwise（两两组合）测试，由组合工具（如 PICT、AllPairs）生成覆盖任意两属性组合的用例集，大幅减少用例数（如 729 降为十余条），同时保持对缺陷发现敏感的两两组合覆盖；引入约束，排除不合法/不可达的组合（如"角色=管理员 且 部门=外部"），避免无效用例；按风险加权，对关键敏感属性（如写入、删除权限）提高覆盖度，对次要属性降维。生成后需补充边界与业务关键组合。Pairwise 的核心是"在可控用例数下最大化组合覆盖"，适合 ABAC 高维权限验证。

组合爆炸是 ABAC 测试的主要挑战。Pairwise+约束+风险加权能在可控用例数下覆盖关键组合，测试者应借组合工具生成高覆盖用例。

• Refresh Token 轮换机制
• 轮换后旧 Token 失效验证
• Token 撤销与黑名单

Refresh Token 轮换（rotation）指每次刷新时发放新 Refresh Token 并使旧 Token 失效，是防重放与劫持的关键。测试重点：验证轮换后旧 Refresh Token 立即失效——用旧 Token 再次刷新应被拒绝，且新 Token 可正常使用；验证轮换是否可重用检测（reuse detection）——若攻击者重放已轮换的旧 Token，应触发告警并使该会话链全部失效；验证 Token 的绑定（绑定到客户端/设备）与撤销（revocation）机制——用户退出或泄露时，Refresh Token 加入黑名单/撤销列表，立即失效。测试应覆盖：轮换的前后一致性、并发刷新是否导致旧 Token 意外失效、撤销后的 Token 无法再换取新 Access Token。通过轮换+撤销+重放检测，确保 Refresh Token 生命周期安全可控。

Refresh Token 生命周期长，是重放攻击的重点。测试应验证轮换后旧 Token 立即失效、撤销生效与重放检测，防止 Token 被长期滥用。

• Scope 权限粒度的测试
• Scope 降级攻击验证
• 越权访问（超出授权 Scope）测试

OAuth 2.0 的 Scope 定义客户端可访问的权限范围，测试需覆盖：Scope 请求验证，客户端请求的 Scope 是否被正确授予、过多或过大的 Scope 是否被拒绝；Scope 降级（privilege escalation 的反面），验证资源服务器是否严格按授予的 Scope 校验，客户端是否能用未授予的 Scope 访问（如只授予读取却尝试写入），即越权访问——攻击者替换/篡改 Scope 参数或使用高权限 token 访问应被拒绝；Scope 一致性，验证资源服务器校验的 Scope 与授权服务器授予的一致，防止被篡改。测试用不同 Scope 的 token 访问资源，验证服务端按 Scope 强制校验，而非信任客户端声明。同时验证 Scope 与角色/资源的映射正确，防止"最小权限"被绕过。

Scope 是资源访问的"权限边界"。测试应验证资源服务器按 token 的 Scope 强制校验，防降级与越权，并确认 Scope 与资源映射一致。

• PIA/DPIA 与测试计划的结合
• 隐私风险转化为测试项
• 数据最小化原则的验证

隐私影响评估（PIA/DPIA）识别系统处理个人数据的风险，其输出应融入测试计划：将 DPIA 识别的隐私风险（如过度收集、数据泄露、未授权共享）转化为具体测试项，纳入测试范围与优先级；对高风险数据处理（新功能、新数据流）设计专项隐私测试用例；并将 DPIA 要求的数据保护措施（加密、访问控制、留存限制）作为测试验证点。数据最小化原则的验证：检查系统是否只收集实现功能所必需的数据，测试验证是否请求了多余字段、是否在非必要场景收集敏感数据、是否在数据达到留存期限后删除——通过记录 API 请求字段、核对数据模型与存储、验证收集与删除逻辑，确认系统遵循"够用即可"的最小化原则。PIA 与测试计划打通，使隐私要求从评估走向可执行的验证。

DPIA 是隐私测试的"输入蓝图"。测试者应把 DPIA 的风险与要求转化为测试项，并验证数据最小化在实际数据流中落实。

• RBAC 与 ABAC 混合模型
• 权限决策的组合逻辑
• 决策一致性与冲突处理

RBAC（基于角色）与 ABAC（基于属性）混合系统被广泛使用，测试需验证权限决策的正确性与一致性。混合模型决策逻辑：通常先按 RBAC 角色确定基础权限，再用 ABAC 属性条件（如部门、时间、资源敏感度）叠加约束，形成"角色+属性"的联合决策。测试要点：一是正确性，验证各角色+属性组合下的预期权限与实际一致，覆盖授权矩阵；二是一致性，验证同一条件下不同入口/模块的决策一致，避免同一用户在不同接口权限不同；三是冲突处理，验证当 RBAC 允许但 ABAC 拒绝（或反之）时决策引擎的优先级/合并规则是否确定，无歧义。测试采用组合方法生成角色×属性用例，对比决策引擎输出与预期权限矩阵，并重点验证边界与冲突场景。混合模型易产生"权限漂移"，需持续测试保证一致性。

混合模型的核心是"角色与属性的联合决策"。测试应验证组合逻辑的正确性、跨入口的一致性以及冲突时的确定行为。

• 数据流映射的概念与产出
• 数据流与测试范围的关系
• 数据流映射指导测试设计

数据流映射（Data Flow Mapping）是隐私合规的基础，它记录个人数据从"收集、处理、存储、传输、共享、处置"全生命周期的流动路径，标注数据来源、存储位置、处理者、共享方与留存周期。它指导测试范围：一是确定测试对象——沿数据流识别所有收集点（表单、API）、处理点（业务逻辑）、存储点（数据库、日志）、传输点（接口、第三方）与共享点（下游系统），纳入测试范围；二是识别风险点——数据流中未加密、过量收集、过长留存、无授权共享的环节是隐私测试重点；三是确定测试用例——按数据流映射为每个落脚点设计隐私测试（收集最小化、加密、访问控制、删除、共享合规）。数据流映射让隐私测试"有地图可循"，避免遗漏分散的数据落脚点，确保覆盖完整。

数据流映射是隐私测试的"路线图"。沿数据流确定测试范围与用例，能覆盖主库之外的缓存、日志、第三方等易遗漏处，保证合规验证完整。

• HIPAA 隐私规则与安全规则
• PHI 数据的保护要求
• 医疗系统的测试方法

HIPAA（美国医疗信息隐私法案）对处理受保护健康信息（PHI）的系统有特殊要求。隐私规则：限定 PHI 的使用与披露，要求最小必要原则、患者授权与数据访问；安全规则：要求管理、物理与技术三大保障，包括访问控制、加密、审计跟踪、完整性保护。测试的特殊要求：一是 PHI 数据保护，验证 PHI 在存储与传输中加密、访问按角色授权、脱敏与访问日志；二是审计跟踪，验证对 PHI 的访问、修改、披露被完整记录，支持违规追溯；三是数据最小化与授权，验证 PHI 仅按授权目的使用，患者可行使访问/更正/告知权；四是安全事件，验证数据泄露的检测与响应。方法上结合数据流映射、权限矩阵、日志审计与加密配置检查，并针对 PHI 数据类型做专项覆盖。HIPAA 测试以"合规+安全"双线确保 PHI 全生命周期受保护。

HIPAA 测试既要保隐私合规（使用/披露/最小化），也要保安全（加密/访问/审计）。测试者应围绕 PHI 数据流做权限、加密、审计与合规专项验证。

• 授权码模式的场景与测试重点
• 隐式模式与 PKCE 场景
• 客户端凭证模式

OAuth 2.0 四种授权模式：授权码模式（Authorization Code），适用于有后端服务器的 Web 应用，最安全，测试重点为 state 防 CSRF、code 一次性、client 认证、PKCE；隐式模式（Implicit），适用于纯前端/SPA，token 直接返回浏览器，安全较弱，现代实践推荐用授权码+PKCE 替代，若使用需重点测 token 泄漏与重定向；客户端凭证模式（Client Credentials），适用于服务间（machine-to-machine）授权，无用户参与，测试重点为 client 凭证保护、scope 最小化、服务端认证；资源所有者密码模式（ROPC），适用于高度信任的应用，用户直接提交密码换 token，安全较弱，测试重点为凭证传输加密、防暴力与会话管理。测试者应确保应用按其架构选择最安全的模式，并针对所选模式验证对应安全控制。

四种模式对应不同客户端架构与安全等级。测试重点随模式而异，核心是"选择最安全可行的模式并验证其安全控制"。

• Discovery 端点的信息泄露风险
• Dynamic Registration 的滥用风险
• 元数据验证与信任

OIDC 的 Discovery 端点（如 /.well-known/openid-configuration）公开了授权服务器元数据（端点 URL、算法、Scope 等），测试要点：验证端点是否泄露敏感信息（如内部端点、调试信息）、是否允许未授权访问、元数据是否被篡改（如攻击者诱导客户端使用恶意端点）；测试应验证信任配置——客户端是否从可信来源获取元数据、是否校验 issuer 与端点域名。Dynamic Registration 端点允许客户端动态注册，测试要点：验证注册是否需授权（如注册令牌）、是否限制注册数量与 scope、是否验证 redirect_uri 白名单、是否防恶意客户端滥用（如注册后获取高权限）；测试应验证动态注册客户端的权限被最小化、redirect_uri 严格校验、以及注册记录可追踪。两端点都需防"供应链式"攻击——攻击者伪造端点或注册恶意客户端诱导授权。

Discovery 与 Dynamic Registration 是 OIDC 信任链的入口，易被篡改与滥用。测试应验证元数据信任、端点的访问控制与注册的授权校验。

• 正向测试与负向测试的定义
• 配比与覆盖策略
• 负向测试的价值

权限测试需兼顾正向与负向：正向测试验证合法用户能成功访问其授权资源（授权访问成功），确保功能可用、不误伤；负向测试验证未授权访问被拒绝（未授权用户、越权、未登录、无权限角色），确保权限边界有效。配比与覆盖策略：负向测试应占较高比重（安全漏洞多在负向），从授权矩阵出发，对每个"角色×资源×操作"组合同时做正向与负向用例，覆盖"应有权限能用、无权限被拒"；针对敏感操作（写入、删除、导出）重点做负向测试；覆盖未登录、Session 过期、低权限访问高权限、IDOR 修改资源 ID 等典型场景。同时验证拒绝的响应（状态码、无数据泄露）与审计日志。策略核心是"以权限矩阵为基准，正负向成对覆盖"，避免只测正向而漏测越权。

权限测试的成败在负向覆盖。以授权矩阵为骨架，正负向成对设计，重点覆盖越权与敏感操作，才能既保可用又堵漏洞。

• Cookie 同意机制（GDPR/ePrivacy）
• 同意前不加载追踪
• 同意状态的持久与撤销

Cookie 同意与追踪授权是 GDPR 与 ePrivacy 的合规要求，测试需验证：一是同意前，非必要 Cookie 与追踪脚本（分析、广告、跨站追踪）不得在用户同意前加载，验证首次访问时只加载必要 Cookie，无追踪脚本执行；二是同意后，用户同意后追踪类 Cookie 才被加载，且按选择类别加载（必要/分析/广告区分）；三是同意状态持久与撤销，验证用户的同意选择被记住（再次访问不回退）、用户能随时撤销同意、撤销后追踪 Cookie 停止并删除；四是同意 UI 与记录，验证同意弹窗的清晰性、选择可记录（供审计）、以及第三方 Cookie 的告知。测试方法：用浏览器 DevTools 观察请求与 Cookie 加载时序、清缓存验证同意状态、审查脚本加载逻辑，确保"同意前置、分类加载、可撤销"的合规闭环。

同意管理测试的核心是"同意前置与可撤销"。验证同意前不加载追踪、同意后按类加载、撤销后停止，保持合规与用户选择一致。