11. 安全考虑

本节旨在告知开发者, 信息提供者和用户与 HTTP 消息语法和解析相关的已知安全考虑. 关于 HTTP 语义, 内容和路由的安全考虑在 [HTTP] 中讨论.

11.1. 响应拆分

响应拆分 (也称为 CRLF 注入) 是 Web 使用中多种攻击采用的一种常见技术, 它利用 HTTP 消息分帧的基于行的性质, 以及持久连接上请求到响应的有序关联 [Klein]. 当请求经过共享缓存时, 这种技术可能特别有破坏性.

响应拆分利用服务器 (通常在应用服务器内) 的漏洞: 攻击者可以在请求的某个参数中发送编码数据, 该数据随后被解码并回显到响应的任一响应头字段中. 如果解码后的数据被构造成看起来像响应已经结束且后续响应已经开始, 则响应已被拆分, 表观第二个响应中的内容由攻击者控制. 然后攻击者可以在同一持久连接上发出任何其他请求, 并诱使接收方 (包括中介) 相信拆分出的后半部分是对第二个请求的权威回答.

例如, request-target 中的一个参数可能被应用服务器读取并在重定向中复用, 导致同一参数回显到响应的 Location 头字段中. 如果该参数由应用解码, 但放入响应字段时未被正确编码, 攻击者就可以发送编码后的 CRLF 八位组和其他内容, 使应用的单个响应看起来像两个或更多响应.

一种常见的响应拆分防御方式是过滤请求中看起来像编码 CR 和 LF 的数据 (例如 "%0D" 和 "%0A"). 然而, 这假定应用服务器只执行 URI 解码, 而不是执行字符集转码, XML 实体转换, base64 解码, sprintf 重新格式化等更隐蔽的数据转换. 更有效的缓解措施是防止服务器核心协议库之外的任何组件在头部区段内发送 CR 或 LF, 这意味着将头字段输出限制到会过滤不良八位组的 API, 并且不允许应用服务器直接写入协议流.

11.2. 请求走私

请求走私 ([Linhart]) 是一种利用各接收方之间协议解析差异的技术, 它在表面无害的请求中隐藏额外请求 (这些请求本来可能被策略阻止或禁用). 与响应拆分类似, 请求走私可能导致针对 HTTP 使用的多种攻击.

本规范引入了新的请求解析要求, 尤其是第 6.3 节关于消息分帧的要求, 以降低请求走私的有效性.

11.3. 消息完整性

HTTP 没有定义用于确保消息完整性的特定机制, 而是依赖底层传输协议的错误检测能力, 以及使用长度定界或 chunk 定界的分帧来检测完整性. 历史上, 缺少单一完整性机制一直以大多数 HTTP 通信的非正式性质作为理由. 然而, HTTP 作为信息访问机制的普及, 已使其越来越多地用于消息完整性验证至关重要的环境.

"https" 方案提供的机制 (例如认证加密) 可以防止消息被修改. 但是, 需要小心确保连接关闭不能被用于截断消息 (见第 9.8 节). 用户代理可能拒绝接受不完整消息, 或对其进行特殊处理. 例如, 用于查看病史或药物相互作用信息的浏览器, 在协议检测到此类信息在传输期间不完整, 已过期或已损坏时, 需要向用户指出. 这类机制可以通过用户代理扩展或响应中存在的消息完整性元数据选择性启用.

"http" 方案不提供防止消息被意外或恶意修改的保护.

协议扩展可用于缓解中介不期望地修改消息的风险, 即使使用 "https" 方案也是如此. 可以使用消息认证码或数字签名来保证完整性, 这些认证码或签名通过可扩展元数据字段选择性地添加到消息中.

11.4. 消息机密性

当需要消息机密性时, HTTP 依赖底层传输协议提供该属性. HTTP 被专门设计为独立于传输协议, 因而可以运行在多种形式的加密连接之上; 这些传输的选择由 URI 方案或用户代理配置标识.

"https" 方案可用于标识需要机密连接的资源, 如 [HTTP] 第 4.2.2 节所述.