HAProxy forwards authority format URI with differences HTTP Method, in violation of RFC 9110 about haproxy

[wtarreau]

These tests are more surface tests than anything else. Internally the whole URI is conveyed along the path, and it is analyzed by the various parts that need it (e.g. path() sample fetch function, etc). If, for example, you observe the same request received over H1 and forwarded over H2, you'll see it split this way (and rejected by the next hop since the path does not start with / and is not *):

[00|h2|1|mux_h2.c:5308] h2c_dec_hdrs(): h2c=0x122a2d0(F,FRP) dsi=1 rcvh :method: GET
[00|h2|1|mux_h2.c:5308] h2c_dec_hdrs(): h2c=0x122a2d0(F,FRP) dsi=1 rcvh :scheme: https
[00|h2|1|mux_h2.c:5308] h2c_dec_hdrs(): h2c=0x122a2d0(F,FRP) dsi=1 rcvh :path: admin

We've seen what can be cleaned up, but again, it really has no impact beyond not being pretty.

[wtarreau]

Thanks for your report. I'm wondering when we broke that, we'll have a look.

[wtarreau]

So we had a look and actually it's not an authority that is passed, it's the path, and it's not modified along the path. If you replace the server behind with a standard netcat, you'll see that "GET admin" is sent as-is, there's no transformation such as prepending a slash. It's basically as if you were passing through a TCP proxy. It's still supported for historical/legacy reasons (normally paths should either begin with '/' or be exactly '*' but only for the OPTIONS method).

One could argue that this could expose vulnerable servers, such as the one you're showing that is incorrectly prepending a '/' in front of the requests it receives, but one could also argue that the goal of a reverse proxy is to be the most transparent possible and not necessarily to try to plug all possible holes of servers behind.

We've discussed about possibly enforcing '/' or '*' by default for paths in 3.1, that could be an acceptable breaking change I think, given that broken applications relying on paths not starting with '/' should not exist anymore.

[vtgsxx]

So we had a look and actually it's not an authority that is passed, it's the path, and it's not modified along the path. If you replace the server behind with a standard netcat, you'll see that "GET admin" is sent as-is, there's no transformation such as prepending a slash. It's basically as if you were passing through a TCP proxy. It's still supported for historical/legacy reasons (normally paths should either begin with '/' or be exactly '*' but only for the OPTIONS method).

One could argue that this could expose vulnerable servers, such as the one you're showing that is incorrectly prepending a '/' in front of the requests it receives, but one could also argue that the goal of a reverse proxy is to be the most transparent possible and not necessarily to try to plug all possible holes of servers behind.

We've discussed about possibly enforcing '/' or '*' by default for paths in 3.1, that could be an acceptable breaking change I think, given that broken applications relying on paths not starting with '/' should not exist anymore.

I see that in include/haproxy/http.h, the http_uri_parser_init will set parser.format to URI_PARSER_FORMAT_ABSURI_OR_AUTHORITY if first character of URI not start with * or /

Latterly, in src/http.c if the http_parse_path doesn't found a scheme (using http_parse_scheme ), then it indicates that the URI is in authority format and the path won't be present

So with "GET admin", HAProxy currently doesn't see "admin" as path (this is why ACL path rule will not detect "admin" to reject the request), or am I in a mistaken way?

[vtgsxx]

I see your point. Thanks.

[capflam]

Some patches were pushed to fix this issue. With Willy, we decided to be stricter on the target request parsing. So, it should be good now. However, the main fix will not be backported because it is a breaking change. And it is still annoying to perform this kind of changes in stable versions. Thanks !