.NET Web 安全试题 03：Token 验证、刷新与密钥轮换
041 关于签名验证，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明
- B. 能够解析 payload 就证明 JWT 未被修改
- C. 算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择
- D. 只要观察到“伪造声明绕过权限检查”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了签名验证可直接依赖的规则：“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”。“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”是应用规则前必须确认的边界，不是规则本身；“能够解析 payload 就证明 JWT 未被修改”则把常见现象或实现细节扩大成了平台保证。场景“伪造声明绕过权限检查”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
042 生产环境出现“伪造声明绕过权限检查”时，针对签名验证应如何排查？
难度： 进阶
- A. 直接采用“能够解析 payload 就证明 JWT 未被修改”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”的验证。
- C. 只检查代码是否能够编译，通过后便认定“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”在当前部署中必然成立。
- D. 先验证“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”，再使用运行时指标、日志或最小复现检查“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”是否成立。
查看答案与解析
正确答案D
“伪造声明绕过权限检查”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”，再以“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”组织证据。采用误区“能够解析 payload 就证明 JWT 未被修改”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
043 评审签名验证相关实现时，以下哪项判断不成立？
难度： 实战
- A. API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明
- B. 能够解析 payload 就证明 JWT 未被修改
- C. 算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择
- D. 遇到“伪造声明绕过权限检查”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“能够解析 payload 就证明 JWT 未被修改”正是签名验证的典型误区。主规则“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”描述了实现应依赖的契约，边界“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
044 准备上线涉及签名验证的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“能够解析 payload 就证明 JWT 未被修改”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”修改代码，但不核对“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”或目标发布模式。
- C. 依据“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”实现，在“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”成立的环境中验证，并为“伪造声明绕过权限检查”保留可观测证据和回退条件。
- D. 只验证“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”，实现仍继续依赖“能够解析 payload 就证明 JWT 未被修改”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“API 必须使用受信发行者的当前签名密钥验证令牌完整性，不能只 Base64 解码声明”，部署环境满足“算法、密钥来源和允许列表需要固定，不能由不可信令牌任意选择”，并能在“伪造声明绕过权限检查”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
045 关于issuer 与 audience，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 签名有效即可跳过发行者和受众
- B. 令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配
- C. 多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者
- D. 只要观察到“测试租户令牌进入生产 API”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了issuer 与 audience可直接依赖的规则：“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”。“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”是应用规则前必须确认的边界，不是规则本身；“签名有效即可跳过发行者和受众”则把常见现象或实现细节扩大成了平台保证。场景“测试租户令牌进入生产 API”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
046 生产环境出现“测试租户令牌进入生产 API”时，针对issuer 与 audience应如何排查？
难度： 进阶
- A. 直接采用“签名有效即可跳过发行者和受众”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”的验证。
- C. 只检查代码是否能够编译，通过后便认定“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”在当前部署中必然成立。
- D. 先验证“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”，再使用运行时指标、日志或最小复现检查“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”是否成立。
查看答案与解析
正确答案D
“测试租户令牌进入生产 API”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”，再以“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”组织证据。采用误区“签名有效即可跳过发行者和受众”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
047 评审issuer 与 audience相关实现时，以下哪项判断不成立？
难度： 实战
- A. 令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配
- B. 多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者
- C. 签名有效即可跳过发行者和受众
- D. 遇到“测试租户令牌进入生产 API”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“签名有效即可跳过发行者和受众”正是issuer 与 audience的典型误区。主规则“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”描述了实现应依赖的契约，边界“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
048 准备上线涉及issuer 与 audience的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”实现，在“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”成立的环境中验证，并为“测试租户令牌进入生产 API”保留可观测证据和回退条件。
- B. 依据“签名有效即可跳过发行者和受众”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”修改代码，但不核对“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”或目标发布模式。
- D. 只验证“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”，实现仍继续依赖“签名有效即可跳过发行者和受众”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“令牌验证应确认 issuer 和 audience 与当前信任域及 API 匹配”，部署环境满足“多租户场景需要显式租户验证策略，不能接受任意格式正确的发行者”，并能在“测试租户令牌进入生产 API”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
049 关于时间声明，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 客户端本地时间正确就能替代 API 的时间验证
- B. 过大 ClockSkew 会延长失效窗口，服务器时钟也需同步
- C. 只要观察到“令牌过期后仍被接受数分钟”，就能把这次现象视为所有环境中的固定行为。
- D. exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据
查看答案与解析
正确答案D
正确项给出了时间声明可直接依赖的规则：“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”。“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”是应用规则前必须确认的边界，不是规则本身；“客户端本地时间正确就能替代 API 的时间验证”则把常见现象或实现细节扩大成了平台保证。场景“令牌过期后仍被接受数分钟”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
050 生产环境出现“令牌过期后仍被接受数分钟”时，针对时间声明应如何排查？
难度： 进阶
- A. 先验证“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”，再使用运行时指标、日志或最小复现检查“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”是否成立。
- B. 直接采用“客户端本地时间正确就能替代 API 的时间验证”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”的验证。
- D. 只检查代码是否能够编译，通过后便认定“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”在当前部署中必然成立。
查看答案与解析
正确答案A
“令牌过期后仍被接受数分钟”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”，再以“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”组织证据。采用误区“客户端本地时间正确就能替代 API 的时间验证”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
051 评审时间声明相关实现时，以下哪项判断不成立？
难度： 实战
- A. exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据
- B. 客户端本地时间正确就能替代 API 的时间验证
- C. 过大 ClockSkew 会延长失效窗口，服务器时钟也需同步
- D. 遇到“令牌过期后仍被接受数分钟”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“客户端本地时间正确就能替代 API 的时间验证”正是时间声明的典型误区。主规则“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”描述了实现应依赖的契约，边界“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
052 准备上线涉及时间声明的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“客户端本地时间正确就能替代 API 的时间验证”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”修改代码，但不核对“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”或目标发布模式。
- C. 依据“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”实现，在“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”成立的环境中验证，并为“令牌过期后仍被接受数分钟”保留可观测证据和回退条件。
- D. 只验证“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”，实现仍继续依赖“客户端本地时间正确就能替代 API 的时间验证”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“exp、nbf 等时间声明应结合可信时钟和有限偏差验证，过期令牌不能继续作为长期凭据”，部署环境满足“过大 ClockSkew 会延长失效窗口，服务器时钟也需同步”，并能在“令牌过期后仍被接受数分钟”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
053 关于刷新令牌轮换，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响
- B. 刷新令牌只是更长的 access token，可发送给所有资源 API
- C. 轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链
- D. 只要观察到“被盗刷新令牌长期换取新令牌”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了刷新令牌轮换可直接依赖的规则：“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”。“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”是应用规则前必须确认的边界，不是规则本身；“刷新令牌只是更长的 access token，可发送给所有资源 API”则把常见现象或实现细节扩大成了平台保证。场景“被盗刷新令牌长期换取新令牌”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
054 生产环境出现“被盗刷新令牌长期换取新令牌”时，针对刷新令牌轮换应如何排查？
难度： 进阶
- A. 直接采用“刷新令牌只是更长的 access token，可发送给所有资源 API”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”，再使用运行时指标、日志或最小复现检查“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”的验证。
- D. 只检查代码是否能够编译，通过后便认定“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”在当前部署中必然成立。
查看答案与解析
正确答案B
“被盗刷新令牌长期换取新令牌”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”，再以“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”组织证据。采用误区“刷新令牌只是更长的 access token，可发送给所有资源 API”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
055 评审刷新令牌轮换相关实现时，以下哪项判断不成立？
难度： 实战
- A. 刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响
- B. 轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链
- C. 遇到“被盗刷新令牌长期换取新令牌”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. 刷新令牌只是更长的 access token，可发送给所有资源 API
查看答案与解析
正确答案D
题目要求找出不成立的判断，“刷新令牌只是更长的 access token，可发送给所有资源 API”正是刷新令牌轮换的典型误区。主规则“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”描述了实现应依赖的契约，边界“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
056 准备上线涉及刷新令牌轮换的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“刷新令牌只是更长的 access token，可发送给所有资源 API”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”修改代码，但不核对“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”或目标发布模式。
- C. 依据“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”实现，在“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”成立的环境中验证，并为“被盗刷新令牌长期换取新令牌”保留可观测证据和回退条件。
- D. 只验证“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”，实现仍继续依赖“刷新令牌只是更长的 access token，可发送给所有资源 API”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“刷新令牌应高强度保护，并可采用轮换和重用检测降低长期凭据泄露影响”，部署环境满足“轮换状态需要服务端记录或等效机制，不能只签发新令牌而不失效旧链”，并能在“被盗刷新令牌长期换取新令牌”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
057 关于签名密钥轮换，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 轮换时立即删除所有旧密钥不会影响尚未过期令牌
- B. 验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换
- C. 旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调
- D. 只要观察到“轮换后部分实例间歇验证失败”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了签名密钥轮换可直接依赖的规则：“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”。“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”是应用规则前必须确认的边界，不是规则本身；“轮换时立即删除所有旧密钥不会影响尚未过期令牌”则把常见现象或实现细节扩大成了平台保证。场景“轮换后部分实例间歇验证失败”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
058 生产环境出现“轮换后部分实例间歇验证失败”时，针对签名密钥轮换应如何排查？
难度： 进阶
- A. 直接采用“轮换时立即删除所有旧密钥不会影响尚未过期令牌”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”的验证。
- C. 先验证“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”，再使用运行时指标、日志或最小复现检查“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”在当前部署中必然成立。
查看答案与解析
正确答案C
“轮换后部分实例间歇验证失败”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”，再以“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”组织证据。采用误区“轮换时立即删除所有旧密钥不会影响尚未过期令牌”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
059 评审签名密钥轮换相关实现时，以下哪项判断不成立？
难度： 实战
- A. 轮换时立即删除所有旧密钥不会影响尚未过期令牌
- B. 验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换
- C. 旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调
- D. 遇到“轮换后部分实例间歇验证失败”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“轮换时立即删除所有旧密钥不会影响尚未过期令牌”正是签名密钥轮换的典型误区。主规则“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”描述了实现应依赖的契约，边界“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
060 准备上线涉及签名密钥轮换的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“轮换时立即删除所有旧密钥不会影响尚未过期令牌”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”修改代码，但不核对“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”或目标发布模式。
- C. 只验证“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”，实现仍继续依赖“轮换时立即删除所有旧密钥不会影响尚未过期令牌”这一未经证明的假设。
- D. 依据“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”实现，在“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”成立的环境中验证，并为“轮换后部分实例间歇验证失败”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“验证端应缓存元数据并在未知 key id 等情况下受控刷新，以兼容发行方密钥轮换”，部署环境满足“旧密钥保留窗口、刷新频率和故障回退必须与令牌寿命协调”，并能在“轮换后部分实例间歇验证失败”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。