11. Security Considerations (安全考虑)

本节旨在告知开发人员、信息提供者和用户有关 HTTP 消息语法和解析相关的已知安全考虑事项。有关 HTTP 语义、内容和路由的安全考虑在 [HTTP] 中阐述。

11.1. Response Splitting (响应拆分)

响应拆分（又称 CRLF 注入）是一种常见技术，用于各种针对 Web 使用的攻击中，它利用了 HTTP 消息帧的基于行的性质以及持久连接上请求到响应的有序关联 [Klein]。当请求通过共享缓存时，这种技术可能特别具有破坏性。

响应拆分利用服务器（通常在应用服务器内）中的漏洞，攻击者可以在请求的某些参数中发送编码数据，这些数据随后被解码并在响应的任何响应头字段中回显。如果解码的数据被制作成看起来像响应已结束且后续响应已开始，则响应已被拆分，明显的第二个响应中的内容由攻击者控制。然后，攻击者可以在同一持久连接上发出任何其他请求，并欺骗接收方（包括中介）相信拆分的后半部分是对第二个请求的权威答案。

例如，请求目标中的参数可能被应用服务器读取并在重定向中重用，导致相同的参数在响应的 Location 头字段中回显。如果参数被应用程序解码并且在放入响应字段时没有正确编码，攻击者可以发送编码的 CRLF 八位字节和其他内容，这将使应用程序的单个响应看起来像两个或更多响应。

针对响应拆分的常见防御是过滤看起来像编码的 CR 和 LF 的数据的请求（例如 "%0D" 和 "%0A"）。但是，这假设应用服务器仅执行 URI 解码，而不是更复杂的数据转换，如字符集转码、XML 实体转换、base64 解码、sprintf 重新格式化等。更有效的缓解措施是防止服务器的核心协议库之外的任何东西在头部分中发送 CR 或 LF，这意味着将头字段的输出限制为过滤坏八位字节的 API，并且不允许应用服务器直接写入协议流。

11.2. Request Smuggling (请求走私)

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

本规范引入了对请求解析的新要求，特别是关于第 6.3 节中的消息帧，以降低请求走私的有效性。

11.3. Message Integrity (消息完整性)

HTTP 没有定义确保消息完整性的特定机制，而是依赖于底层传输协议的错误检测能力以及使用长度或块界定的帧来检测完整性。从历史上看，缺乏单一的完整性机制是由大多数 HTTP 通信的非正式性质所证明的。然而，HTTP 作为信息访问机制的普及导致其在验证消息完整性至关重要的环境中越来越多地使用。

"https" 方案提供的机制（如认证加密）提供了针对消息修改的保护。但是，需要注意确保连接关闭不能用于截断消息（参见第 9.8 节）。用户代理可能会拒绝接受不完整的消息或对其进行特殊处理。例如，用于查看医疗历史或药物相互作用信息的浏览器需要在协议检测到此类信息在传输过程中不完整、过期或损坏时向用户指示。这些机制可能通过用户代理扩展或响应中存在消息完整性元数据而有选择地启用。

"http" 方案不提供针对意外或恶意修改消息的保护。

即使使用 "https" 方案，也可以使用协议扩展来降低中介不需要的消息修改风险。完整性可以通过使用消息认证码或数字签名来保证，这些码或签名通过可扩展的元数据字段有选择地添加到消息中。

11.4. Message Confidentiality (消息机密性)

当需要消息机密性时，HTTP 依赖于底层传输协议来提供。HTTP 被特意设计为独立于传输协议，因此可以在许多形式的加密连接上使用，通过选择 URI 方案或在用户代理配置中识别此类传输的选择。

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

---