Skip to content

Issues in Parsing HTTP Request "Host" Header #462

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
TUO-Wu opened this issue Mar 19, 2025 · 1 comment
Open

Issues in Parsing HTTP Request "Host" Header #462

TUO-Wu opened this issue Mar 19, 2025 · 1 comment

Comments

@TUO-Wu
Copy link

TUO-Wu commented Mar 19, 2025

Hello, I may find some bugs with the Host header where waitress parses HTTP requests.
RFC 9112 says this:

A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field line or a Host header field with an invalid field value.

This should imply that the HTTP server must reject requests with redundant Host headers or requests with missing Host headers. But in both cases, waitress did not reject.

Examples:

POST / HTTP/1.1\r\n
Host: victim1.com\r\n
Host: victim2.com\r\n
\r\n
$ echo -ne "POST / HTTP/1.1\r\nHost: victim1.com\r\nHost: victim2.com\r\n\r\n" | nc 172.18.0.6 80
HTTP/1.1 200 OK
Content-Length: 129
Content-Type: application/json
Date: Wed, 19 Mar 2025 15:29:06 GMT
Server: waitress

{"headers":[["SE9TVA==","dmljdGltMS5jb20sIHZpY3RpbTIuY29t"]],"body":"","version":"SFRUUC8xLjE=","uri":"Lw==","method":"UE9TVA=="}

or

POST / HTTP/1.1\r\n
Content-Length: 0\r\n
\r\n
$ echo -ne "POST / HTTP/1.1\r\nContent-Length: 0\r\n\r\n" | nc 172.18.0.6 80
HTTP/1.1 200 OK
Content-Length: 113
Content-Type: application/json
Date: Wed, 19 Mar 2025 15:29:31 GMT
Server: waitress

{"headers":[["Q09OVEVOVF9MRU5HVEg=","MA=="]],"body":"","version":"SFRUUC8xLjE=","uri":"Lw==","method":"UE9TVA=="}

The version I tested: fc592e8

@kgaughan
Copy link
Member

I'm not going to close this out straight away, but you do need to keep in mind that Waitress is not intended to be exposed to the internet. It's intended to be either (a) used for development or (b) used behind a reverse proxy that provides TLS termination and to also deal with said nuances of HTTP. In other words, the HTTPS headers ought to be normalised before Waitress even sees them. Can you construct an attack where the likes of Apache, Nginx, or Caddy are in front of Waitress.

I've used this response to a number of issues so far. Unless you're opening an issue that makes sense in the context of the project, you're effectively just spamming a group of volunteers. If you've an actual set fixes that might make Waitress more robust, I think we're more than willing to accept them, time willing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants