pgjones
HTTP Request Method Parsing Error
Summary
Hypercorn fails to correctly validate HTTP request methods, allowing attackers to exploit malformed methods for HTTP request smuggling attacks, bypassing frontend security measures and accessing backend resources.
Details
RFC 9112 says this:
The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.
This implies that the request method must strictly adhere to the token definition—only specific characters are allowed and case sensitivity must be maintained. Hypercorn’s HTTP request method parser does not strictly enforce these RFC requirements when parsing request methods and accepts non-compliant methods.
Example
PoST / HTTP/1.1\r\n
Host: victim.com\r\n
\r\n
Suggested action Strictly validate HTTP request methods according to RFC specifications and only accept methods that conform to the token definition. Any request with a non-compliant method should be rejected immediately with an appropriate error response.
PoC
The example request is embedded in the previous section. Send the request to the server, e.g. by echo -ne into nc.
Impact
This bug enables attackers to use HTTP request smuggling techniques to bypass front-end proxy security checks, thereby accessing sensitive resources that should remain protected. This can lead to sensitive data leakage and potentially serve as a gateway for further attacks, such as session hijacking or bypassing additional security measures.
The version we tested was 84d06b8.
PoST is a legal HTTP method; case-sensitivity just means that it's a different method from POST. What specifically are you seeing that's wrong?
You are filing an awful lot of these issues where it's super unclear what specifically you observed, why you think it's wrong, with novel interpretations of the RFCs. Is this just being churned out by some spam template or something?
Sorry I may have bothered.
What I want to express is that according to RFC 9112 I mentioned before:
The request method is case-sensitive.
HTTP request methods should be case-sensitive. So the PoST in my example is syntactically valid, but it's a non-standard HTTP request method, and hypercorn doesn't reject it. HTTP servers should reject such non-standard HTTP request methods according to the RFC, otherwise there may be security risks.
The other issues I submitted were for similar reasons. Sorry again for my interruption.
spam template
Unfortunately, there is a point to most of these. All strip() (without specifying which characters) and upper() (in places except those actually case-insensitive) needs a second look. If the proxy validates that all methods except DELETE are fair game, and the application acts on dElEtE as if that was the same, that is bad. If the proxy forwards a message and then
HTTP servers should reject such non-standard HTTP request methods
No. HEAD and CONNECT/OPTIONS/TRACE/OPTIONS have some special rules attached, but being open to OPTIONAL custom methods is perfectly reasonable.
However, the application must see the correct method, lest it concludes an access control check on something other than the method actually sent, and potentially previously checked against proxy ACL.
https://github.com/pgjones/hypercorn/blob/84d06b8cf47798d2df7722273341e720ec0ea102/src/hypercorn/protocol/h11.py#L239
The method of HTTP Upgrade request used to initiate a WebSocket connection is GET, not get, not gEt, ..
https://datatracker.ietf.org/doc/html/rfc6455#section-4.1 https://github.com/pgjones/hypercorn/blob/84d06b8cf47798d2df7722273341e720ec0ea102/src/hypercorn/protocol/h11.py#L202
(and the splitting of the Upgrade header does not comply with stripping only the whitespace permitted in https://datatracker.ietf.org/doc/html/rfc7230#section-7)
