6. 安全考虑 (Security Considerations)
本节旨在向开发者, 信息提供者与用户告知 HTTP 认证特有的已知安全问题. 更一般的安全考虑在 HTTP 消息 [RFC7230] 与语义 [RFC7231] 中讨论.
关于 HTTP 认证的一切都是安全考虑, 因而下述考量列表并不详尽. 此外, 它只限于与认证框架总体相关的安全考虑, 而不讨论特定认证方案的所有潜在考量 (后者应当在定义这些方案的规范中记录). 各种组织维护着 Web 应用安全的专题信息与当前研究链接 (例如 [OWASP]), 包括实践中常见的认证方案实现与使用陷阱.
6.1 凭证的保密性 (Confidentiality of Credentials)
HTTP 认证框架没有定义维护凭证保密性的单一机制; 相反, 每种认证方案自行定义凭证在传输前如何编码. 虽然这为开发未来的认证方案提供了灵活性, 但对于自身不提供保密性, 或不足以防范重放攻击的既有方案而言, 这是不充分的. 此外, 如果服务器期望每个用户专有的凭证, 那么交换这些凭证将起到识别该用户的作用, 即便凭证内容保持机密.
HTTP 依赖底层传输层或会话层连接的安全属性来提供头部字段的保密传输. 换言之, 如果服务器使用本框架限制只有已认证用户才能访问, 那么服务器需要确保按照所用认证方案的性质对连接进行恰当的保护. 例如, 依赖个人用户认证的服务通常要求先用 TLS ("Transport Layer Security", [RFC5246]) 保护连接, 再交换任何凭证.
6.2 认证凭证与空闲客户端 (Authentication Credentials and Idle Clients)
现有的 HTTP 客户端与用户代理通常无限期地保留认证信息. HTTP 没有提供让源服务器指示客户端丢弃这些缓存凭证的机制, 因为协议无从知晓凭证由用户代理如何获取或管理. 使凭证过期或吊销的机制可以作为认证方案定义的一部分来规定.
凭证缓存可能干扰应用安全模型的情形包括但不限于:
-
长时间空闲的客户端, 之后服务器可能希望促使客户端重新向用户索要凭证.
-
包含会话终止指示 (例如页面上的 "logout" 或 "commit" 按钮) 的应用, 此后应用的服务器端 "知道" 客户端已没有继续保留凭证的理由.
鼓励缓存凭证的用户代理提供一种便于访问的机制, 让用户可以自行控制丢弃缓存的凭证.
6.3 保护空间 (Protection Spaces)
仅依赖 "realm" 机制建立保护空间的认证方案, 会把凭证暴露给源服务器上的所有资源. 已对某资源成功完成认证请求的客户端, 可以把相同的认证凭证用于同一源服务器上的其他资源. 这使得一个不同的资源能够为其他资源收集认证凭证.
当源服务器在同一规范根 URI 下 (第 2.2 节) 为多方托管资源时, 这尤其令人担忧. 可能的缓解策略包括: 限制对认证凭证的直接访问 (即不使 Authorization 请求头部字段的内容可用), 以及通过为每方使用不同的主机名 (或端口号) 来划分保护空间.