Skip to content

Duplicate Content-Type Header Parsing Issue #3366

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 20, 2025 · 0 comments
Open

Duplicate Content-Type Header Parsing Issue #3366

TUO-Wu opened this issue Mar 20, 2025 · 0 comments

Comments

@TUO-Wu
Copy link

TUO-Wu commented Mar 20, 2025

Version
bacbf8a

Platform
Ubuntu 11.4.0-1ubuntu1~22.04

Description
Hello, I may have found a bug in gunicorn's parsing of HTTP requests with duplicate Content-Type header.
RFC 9110 says this:

Although Content-Type is defined as a singleton field, it is sometimes incorrectly generated multiple times, resulting in a combined field value that appears to be a list. Recipients often attempt to handle this error by using the last syntactically valid member of the list, leading to potential interoperability and security issues if different implementations have different error handling behaviors.

Gunicorn does not reject such requests. For example:

POST / HTTP/1.1\r\n
Host: victim.com\r\n
Content-Type: text/plain\r\n
Content-Type: application/json\r\n
\r\n
$ echo -ne "POST / HTTP/1.1\r\nHost: victim.com\r\nContent-Type: text/plain\r\nContent-Type: application/json\r\n\r\n" | nc 172.18.0.7 80
HTTP/1.1 200 OK
Server: gunicorn
Date: Thu, 20 Mar 2025 15:42:12 GMT
Connection: keep-alive
Content-type: application/json
Content-Length: 161

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

Recipients often attempt to handle this error by using the last syntactically valid member of the list, leading to potential interoperability and security issues if different implementations have different error handling behaviors.

If different implementations have different error handling behaviors, there may be potential interoperability and security issues. So I might suggest rejecting such requests.

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

1 participant