HTTP标头中的额外空间在HAProxy上产生400错误 [英] Extra space in HTTP headers gives 400 error on HAProxy

问题描述

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

We switched from citrix to HAProxy for load balancing recently.

问题在于，对于某些请求，HAProxy开始发出400错误(以前在citrix上运行良好).因此，我们暂时从基于HTTP的负载平衡转向了基于TCP的负载平衡.

The Problem is that for some requests HAProxy started giving a 400 Error (Which used to work well on citrix). So we moved to TCP based load balancing from a HTTP based load balancing for the time being.

在进一步调查中，我们发现某些请求的HTTP标头中有多余的空间，这会导致400错误.

On further investigating we found that some requests had an extra space in the HTTP header which caused the 400 error.

profileID<space>:value
vs
profileID:value

这些请求来自android应用，因此我们无法更改源代码.

And these requests came from the android app so we are not able to change the source code.

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

We are trying to move back to http based load balancing.

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

Is there any config setting that may allow us to ignore the space.

推荐答案

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

HAProxy supports a proxy configuration directive called option accept-invalid-http-request.

它放宽了HAProxy默认正确地对传入请求进行要求的某些严格的协议合规性，因此，在不理解其含义的情况下，请勿盲目或粗心地使用它.

It relaxes some of the strict protocol compliance that HAProxy correctly requires by default on incoming requests, so it should not be used blindly or carelessly without understanding the implications.

从文档中:

默认情况下，HAProxy在消息解析方面符合RFC7230.这意味着标头名称中的无效字符是不允许的，并且会导致错误返回给客户端.这是理想的行为，因为这种禁用字符实际上用于利用服务器漏洞进行攻击，并绕过安全过滤.

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.

有时，有问题的浏览器或服务器会出于任何原因(配置，实现)发出无效的标头名称，并且该问题不会立即得到解决.在这种情况下，可以通过指定此选项来放宽HAProxy的标头名称解析器以接受任何字符，即使这没有任何意义.

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.

类似地，RFC3986很好地定义了允许出现在URI中的字符列表，以及字符0-31、32(空格)，34('')，60('<')，62(' >')，92('\')，94('^')，96(''')，123('{')，124('|')，125('}')，127(删除) Haproxy始终会阻止其中的一些(0..32，127).默认情况下，除非启用了此选项，否则其余的默认情况下都将被阻止.此选项还放宽了对HTTP版本的测试，允许HTTP/0.9请求通过(未指定版本)，并且主要版本和次要版本都通过多个数字.

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.

默认情况下，永远不要启用此选项，因为它隐藏了应用程序错误并打开了安全漏洞.仅在确认问题后才部署它.

http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#4-option%20accept-invalid-http-request (添加了重点)

将此选项添加到配置文件的相应frontend部分中，应该可以接受这些无效的标头.

Adding this option to the respective frontend section of your configurarion file should allow these invalid headers to be accepted.

请注意，文档中提到的潜在安全风险不是HAProxy固有的风险，而是针对代理后面堆栈中的漏洞的利用风险-因为通常，HAProxy会将这些组件屏蔽在此类无效请求中.

Note that the potential security risks mentioned in the documentation are not risks inherent in HAProxy, but rather risks of exploits against vulnerabilities in your stack behind the proxy -- because normally, HAProxy shields those components from such invalid requests.

这篇关于HTTP标头中的额外空间在HAProxy上产生400错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！