You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Hello, I may find some bugs with the
Host
header where waitress parses HTTP requests.RFC 9112 says this:
This should imply that the HTTP server must reject requests with redundant
Host
headers or requests with missingHost
headers. But in both cases, waitress did not reject.Examples:
or
The version I tested: fc592e8
The text was updated successfully, but these errors were encountered: