ASP.NET Core 试题 31：HTTPS、HSTS 与 CORS
0601 在 HTTPS 重定向 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口
- B. HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址
- C. API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一
- D. 观察到“客户端 POST 因重定向丢失方法或正文”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 HTTPS 重定向 的主规则：UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口。选项“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”是使用规则时要验证的边界，不是规则本身；“HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0602 客户端 POST 因重定向丢失方法或正文。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址”定性，不再检查配置、身份或运行时证据。
- B. 先验证“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”，再依据“UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”。
- D. 以一次成功请求作为结论，不再确认“UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口”是否成立。
查看答案与解析
正确答案B
场景“客户端 POST 因重定向丢失方法或正文”指向 HTTPS 重定向，但症状本身不能证明根因。正确排查应先确认边界“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”，再用主规则“UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口”解释证据。直接采用误区“HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0603 关于 HTTPS 重定向，以下哪项说法不成立？
难度： 实战
- A. UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口
- B. API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一
- C. 出现“客户端 POST 因重定向丢失方法或正文”时，应收集证据并同时核对主规则与适用边界。
- D. HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址”正是 HTTPS 重定向 的典型误区。其余三项分别给出了主规则“UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口”、适用边界“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0604 针对“客户端 POST 因重定向丢失方法或正文”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址”修改实现，并把一次请求成功作为验收结果。
- B. 按“UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口”修改代码后直接上线，不验证“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”。
- C. 按“UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口”修正实现，并用测试或遥测验证“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”。
- D. 只验证“API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一”，但实现仍继续依赖“HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：UseHttpsRedirection 把 HTTP 请求重定向到配置的 HTTPS 端口；并确认 API 非幂等请求重定向可能被客户端错误处理，生产入口最好直接只接受 HTTPS 或在代理层统一。继续接受“HTTPS 重定向会把所有 HTTP POST 正文安全无损地重放到新地址”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“客户端 POST 因重定向丢失方法或正文”这一生产场景能否安全上线。
0605 在 HSTS 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. HSTS 会自动给服务器安装并续期 TLS 证书
- B. HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机
- C. 首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS
- D. 观察到“证书过期后浏览器无法建立连接”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 HSTS 的主规则：HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机。选项“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”是使用规则时要验证的边界，不是规则本身；“HSTS 会自动给服务器安装并续期 TLS 证书”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0606 证书过期后浏览器无法建立连接。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”，再依据“HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机”判断实现是否符合契约。
- B. 直接按“HSTS 会自动给服务器安装并续期 TLS 证书”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”。
- D. 以一次成功请求作为结论，不再确认“HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机”是否成立。
查看答案与解析
正确答案A
场景“证书过期后浏览器无法建立连接”指向 HSTS，但症状本身不能证明根因。正确排查应先确认边界“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”，再用主规则“HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机”解释证据。直接采用误区“HSTS 会自动给服务器安装并续期 TLS 证书”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0607 关于 HSTS，以下哪项说法不成立？
难度： 实战
- A. HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机
- B. 首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS
- C. HSTS 会自动给服务器安装并续期 TLS 证书
- D. 出现“证书过期后浏览器无法建立连接”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“HSTS 会自动给服务器安装并续期 TLS 证书”正是 HSTS 的典型误区。其余三项分别给出了主规则“HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机”、适用边界“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0608 针对“证书过期后浏览器无法建立连接”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“HSTS 会自动给服务器安装并续期 TLS 证书”修改实现，并把一次请求成功作为验收结果。
- B. 按“HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机”修改代码后直接上线，不验证“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”。
- C. 只验证“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”，但实现仍继续依赖“HSTS 会自动给服务器安装并续期 TLS 证书”。
- D. 按“HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机”修正实现，并用测试或遥测验证“首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：HSTS 响应头要求支持的浏览器在一段时间内只用 HTTPS 访问该主机；并确认 首次访问和不遵循 HSTS 的客户端仍需安全入口，开发 localhost 通常不启用 HSTS。继续接受“HSTS 会自动给服务器安装并续期 TLS 证书”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“证书过期后浏览器无法建立连接”这一生产场景能否安全上线。
0609 在 反向代理与 Scheme 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 任何客户端发送 X-Forwarded-Proto: https 都应被应用信任
- B. TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息
- C. 必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers
- D. 观察到“攻击者伪造 Scheme 绕过安全判断”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 反向代理与 Scheme 的主规则：TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息。选项“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”是使用规则时要验证的边界，不是规则本身；“任何客户端发送 X-Forwarded-Proto: https 都应被应用信任”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0610 攻击者伪造 Scheme 绕过安全判断。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“任何客户端发送 X-Forwarded-Proto: https 都应被应用信任”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”。
- C. 以一次成功请求作为结论，不再确认“TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息”是否成立。
- D. 先验证“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”，再依据“TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“攻击者伪造 Scheme 绕过安全判断”指向 反向代理与 Scheme，但症状本身不能证明根因。正确排查应先确认边界“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”，再用主规则“TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息”解释证据。直接采用误区“任何客户端发送 X-Forwarded-Proto: https 都应被应用信任”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0611 关于 反向代理与 Scheme，以下哪项说法不成立？
难度： 实战
- A. TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息
- B. 必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers
- C. 任何客户端发送 X-Forwarded-Proto: https 都应被应用信任
- D. 出现“攻击者伪造 Scheme 绕过安全判断”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“任何客户端发送 X-Forwarded-Proto: https 都应被应用信任”正是 反向代理与 Scheme 的典型误区。其余三项分别给出了主规则“TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息”、适用边界“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0612 针对“攻击者伪造 Scheme 绕过安全判断”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息”修正实现，并用测试或遥测验证“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”。
- B. 按“任何客户端发送 X-Forwarded-Proto: https 都应被应用信任”修改实现，并把一次请求成功作为验收结果。
- C. 按“TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息”修改代码后直接上线，不验证“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”。
- D. 只验证“必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers”，但实现仍继续依赖“任何客户端发送 X-Forwarded-Proto: https 都应被应用信任”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：TLS 在代理终止时，应用需通过受信转发头恢复原始 Scheme 和客户端信息；并确认 必须限制 KnownProxies 或 KnownNetworks，不能无条件信任公网 Forwarded Headers。继续接受“任何客户端发送 X-Forwarded-Proto: https 都应被应用信任”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“攻击者伪造 Scheme 绕过安全判断”这一生产场景能否安全上线。
0613 在 CORS 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 关闭 CORS 能阻止攻击者直接向 API 发送请求
- B. 策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护
- C. CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护
- D. 观察到“恶意站点表单仍能向服务器提交请求”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 CORS 的主规则：CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护。选项“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”是使用规则时要验证的边界，不是规则本身；“关闭 CORS 能阻止攻击者直接向 API 发送请求”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0614 恶意站点表单仍能向服务器提交请求。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“关闭 CORS 能阻止攻击者直接向 API 发送请求”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”。
- C. 以一次成功请求作为结论，不再确认“CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护”是否成立。
- D. 先验证“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”，再依据“CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“恶意站点表单仍能向服务器提交请求”指向 CORS，但症状本身不能证明根因。正确排查应先确认边界“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”，再用主规则“CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护”解释证据。直接采用误区“关闭 CORS 能阻止攻击者直接向 API 发送请求”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0615 关于 CORS，以下哪项说法不成立？
难度： 实战
- A. 关闭 CORS 能阻止攻击者直接向 API 发送请求
- B. CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护
- C. 策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护
- D. 出现“恶意站点表单仍能向服务器提交请求”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“关闭 CORS 能阻止攻击者直接向 API 发送请求”正是 CORS 的典型误区。其余三项分别给出了主规则“CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护”、适用边界“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0616 针对“恶意站点表单仍能向服务器提交请求”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“关闭 CORS 能阻止攻击者直接向 API 发送请求”修改实现，并把一次请求成功作为验收结果。
- B. 按“CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护”修正实现，并用测试或遥测验证“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”。
- C. 按“CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护”修改代码后直接上线，不验证“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”。
- D. 只验证“策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护”，但实现仍继续依赖“关闭 CORS 能阻止攻击者直接向 API 发送请求”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：CORS 是浏览器对跨源脚本读取响应的限制，服务器到服务器调用不受它保护；并确认 策略应精确允许来源、方法和头；CORS 不是认证、授权或 CSRF 防护。继续接受“关闭 CORS 能阻止攻击者直接向 API 发送请求”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“恶意站点表单仍能向服务器提交请求”这一生产场景能否安全上线。
0617 在 凭据式 CORS 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 允许凭据后响应中的 Cookie 会自动变为跨站安全
- B. 不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信
- C. 观察到“配置通配来源导致浏览器拒绝响应”即可把一次现象当成完整框架契约。
- D. AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据
查看答案与解析
正确答案D
正确答案直接描述 凭据式 CORS 的主规则：AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据。选项“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”是使用规则时要验证的边界，不是规则本身；“允许凭据后响应中的 Cookie 会自动变为跨站安全”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0618 配置通配来源导致浏览器拒绝响应。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“允许凭据后响应中的 Cookie 会自动变为跨站安全”定性，不再检查配置、身份或运行时证据。
- B. 先验证“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”，再依据“AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”。
- D. 以一次成功请求作为结论，不再确认“AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据”是否成立。
查看答案与解析
正确答案B
场景“配置通配来源导致浏览器拒绝响应”指向 凭据式 CORS，但症状本身不能证明根因。正确排查应先确认边界“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”，再用主规则“AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据”解释证据。直接采用误区“允许凭据后响应中的 Cookie 会自动变为跨站安全”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0619 关于 凭据式 CORS，以下哪项说法不成立？
难度： 实战
- A. AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据
- B. 不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信
- C. 允许凭据后响应中的 Cookie 会自动变为跨站安全
- D. 出现“配置通配来源导致浏览器拒绝响应”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“允许凭据后响应中的 Cookie 会自动变为跨站安全”正是 凭据式 CORS 的典型误区。其余三项分别给出了主规则“AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据”、适用边界“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0620 针对“配置通配来源导致浏览器拒绝响应”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据”修正实现，并用测试或遥测验证“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”。
- B. 按“允许凭据后响应中的 Cookie 会自动变为跨站安全”修改实现，并把一次请求成功作为验收结果。
- C. 按“AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据”修改代码后直接上线，不验证“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”。
- D. 只验证“不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信”，但实现仍继续依赖“允许凭据后响应中的 Cookie 会自动变为跨站安全”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：AllowCredentials 允许浏览器在被允许的跨源请求中携带凭据；并确认 不能把 AllowAnyOrigin 与 AllowCredentials 组合，允许来源必须明确且可信。继续接受“允许凭据后响应中的 Cookie 会自动变为跨站安全”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“配置通配来源导致浏览器拒绝响应”这一生产场景能否安全上线。