http - HTTP header 中的额外空间会在 HAProxy 上产生 400 错误

Question

我们最近从 citrix 切换到 HAProxy 以实现负载平衡。

问题是，对于某些请求，HAProxy 开始给出 400 错误(过去在 citrix 上运行良好)。因此，我们暂时从基于 HTTP 的负载平衡转移到基于 TCP 的负载平衡。

在进一步调查中，我们发现一些请求在 HTTP header 中有一个额外的空间，这导致了 400 错误。

profileID<space>:value
vs
profileID:value

并且这些请求来自 android 应用程序，因此我们无法更改源代码。

我们正在尝试回到基于 http 的负载平衡。

是否有任何配置设置可以让我们忽略空格。

Answer 1

HAProxy 支持名为 option accept-invalid-http-request 的代理配置指令。

它放宽了 HAProxy 正确地默认要求对传入请求的一些严格协议(protocol)合规性，因此在不了解其含义的情况下不应盲目或粗心地使用它。

来自文档:

By default, HAProxy complies with RFC7230 in terms of message parsing. This means that invalid characters in header names are not permitted and cause an error to be returned to the client. This is the desired behaviour as such forbidden characters are essentially used to build attacks exploiting server weaknesses, and bypass security filtering.

Sometimes, a buggy browser or server will emit invalid header names for whatever reason (configuration, implementation) and the issue will not be immediately fixed. In such a case, it is possible to relax HAProxy's header name parser to accept any character even if that does not make sense, by specifying this option.

Similarly, the list of characters allowed to appear in a URI is well defined by RFC3986, and chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96 ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are not allowed at all. Haproxy always blocks a number of them (0..32, 127). The remaining ones are blocked by default unless this option is enabled. This option also relaxes the test on the HTTP version, it allows HTTP/0.9 requests to pass through (no version specified) and multiple digits for both the major and the minor version.

This option should never be enabled by default as it hides application bugs and open security breaches. It should only be deployed after a problem has been confirmed.

http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#4-option%20accept-invalid-http-request (emphasis added)

将此选项添加到配置文件的相应 frontend 部分应该允许接受这些无效 header 。

请注意，文档中提到的潜在安全风险不是 HAProxy 固有的风险，而是针对代理背后堆栈中漏洞的利用风险——因为通常情况下，HAProxy 会保护这些组件免受此类无效请求。