7.5.6. Non-List Field Values (非列表字段值)

7.5.6. Non-List Field Values (非列表字段值)

当 HTTP 字段在单条消息中出现多次时, 这些值需要合并为单一单行字符串值以纳入 HTTP 签名基, 如第 2.5 节所述. 并非所有 HTTP 字段都能以此方式合并为单一值且仍为该字段的有效值. 就生成签名基而言, 消息组成部分值从不意味着从签名基字符串读回或在应用中使用. 因此, 最佳实践是将签名基生成算法与应用的字段值处理分开, 特别是对已知具有此属性的字段. 若正在签名的字段值不验证, 签名消息也应被拒绝.

若 HTTP 字段允许值内未加引号的逗号, 合并多个字段值可能导致两个语义不同消息在签名基中产生相同行. 例如, 下列假设头字段语法内部有逗号, 此处用于定义两个单独的值列表:

Example-Header: value, with, lots
Example-Header: of, commas

对该头字段, 将所有这些值作为单一字段值发送产生单一值列表:

Example-Header: value, with, lots, of, commas

这两种消息都会在签名基中产生下列行:

"example-header": value, with, lots, of, commas

由于两种语义不同输入可在签名基产生相同输出, 处理此类值时必须特别小心.

具体地, Set-Cookie 字段 [COOKIE] 定义的内部语法不符合 [STRUCTURED-FIELDS] 提供的 List 语法. 特别地, 某些部分允许未加引号逗号, 发送多个 cookie 时该字段通常作为具有不同值的多个单独字段行发送. 当同一条消息中发送多个 Set-Cookie 字段时, 通常无法将这些合并为单行并仍能解析和使用结果, 见 [HTTP] 第 5.3 节. 因此, 所有 cookie 需要从其单独字段值处理而不合并, 而签名基需要从专为此目的生成的特殊合并值处理. 若 cookie 值无效, 应拒绝签名消息, 因为这是第 7.5.7 节描述的填充攻击.

为处理此点, 应用可选择限制对有问题的字段 (如 Set-Cookie) 的签名, 例如仅在存在单个字段值且结果无歧义时纳入签名. 对所有可能对签名基具有非确定性映射的字段需要类似谨慎. 签名者还可按第 2.1.3 节所述使用 bs 参数加固此类字段.