http标头的安全性

Question

我们希望在发送之前仔细检查我们的http标头的安全性。显然我们不能允许'\ r'或'\ n'出现，因为这会允许内容注入。

我在这里只看到两个选项：

1. 截断换行符处的值。
2. 从标头值中删除无效字符。

此外，从阅读RFC2616开始，似乎只有ascii-printable字符对http标头值有效我是否也应该对其他154个可能的无效字节采用相同的策略？

或者，是否有关于此主题的权威性现有技术？

Answer 1

此攻击称为“标题拆分”或"response splitting"。

OWASP链接指出删除CRLF是不够的。 \n可能同样危险。

  

要挂载成功的漏洞利用程序，应用程序必须允许包含CR（回车符，也由0x0D或\ r \ n）和LF（换行符，也由0x0A或\ n给出）字符的输入包含在标头中。

（我不知道为什么OWASP（和其他页面）将\n列为漏洞，或者是否仅适用于预解码的查询片段。）

在任何尝试设置包含标题键或值中规范不允许的字符的标头时提供500是完全合理的，并且允许您在日志中识别令人反感的请求。当您知道过滤器失败时失败是一个很好的策略。

如果您正在使用的语言允许它，您可以将HTTP响应对象包装在一个在看到错误标题时引发异常的对象，或者您可以更改响应对象以进入无效状态，设置响应代码为500，并关闭响应正文流。

编辑：

  

我应该删除非ASCII输入吗？

我更喜欢在接收受信任输入的层中进行那种规范化，除非在实体转义的情况下将纯文本转换为HTML转义，有明确的类型转换。如果是类型转换，我会在需要输出类型时执行此操作，但如果它不是类型转换，我会尽早完成，以便该类型数据的所有使用者都能看到一致的值。我发现这种方法使调试和文档更容易，因为输入处理下面的层永远不必担心非标准化输入。

当实现HTTP响应包装器时，我会使所有非ascii字符（包括非ASCII新行，如U + 85，U + 2028，U + 2029）失败，然后制作确保我的应用程序测试包括对每个第三方网址输入的测试，以确保在位置到达Location之前对所有setHeader标头进行了正确的％编码，对于可能达到请求的其他输入也是如此头。

如果您的Cookie包含用户ID或电子邮件地址等内容，我会确保测试的虚拟帐户包含一个虚拟帐户，其中包含一个非ASCII字母的用户ID或电子邮件地址。

Answer 2

简单删除新行\n会阻止HTTP Response Splitting。尽管CRLF在RFC中用作分隔符，但所有浏览器都可以识别新行。

您仍然需要担心set-cookie或content-type内的用户内容。这些元素中的属性使用;分隔，攻击者可能会将内容类型更改为UTF-7并绕过对IE用户（仅限IE用户）的XSS保护。攻击者也可能创建一个新的cookie，这引入了会话固定的可能性。

Answer 3

标题字段中允许使用非ASCII字符，尽管规范并没有明确说出它们的含义;所以发件人和收件人都要就他们的语义达成一致。

是什么让你想到的呢？