Strict validation of content length and chunk length.

[ioquatix]

Security researchers @mukeran and @chenjj have reported issues with parsing content length and chunk lengths:

RFC 9112 Section 7.1 defined the format of chunk size, chunk data and chunk extension (detailed ABNF is in Appendix secion).

In a word:

• The value of Content-Length header should be a string of 0-9 digits.
• The chunk size should be a string of hex digits and should split from chunk data using CRLF.
• The chunk extension shouldn't contain any invisible character.

However, we found that Falcon has following behaviors while disobey the corresponding RFCs.

• Falcon accepts Content-Length header values that have "+" prefix.
• Falcon accepts Content-Length header values that written in hexadecimal with "0x" prefix.
• Falcon accepts "0x" and "+" prefixed chunk size.
• Falcon accepts LF in chunk extension.

This behavior can lead to desync when forwarding through multiple HTTP parsers, potentially results in HTTP request smuggling and firewall bypassing.

When sending the following requests to the server, falcon successfully parsed our requests and our application successfully read request body.

Impact

The above is a valid assessment of the behaviour of the HTTP/1 parser. However, as this gem does not expose the raw body or forward it in any way, I don't believe it can cause issues in the real world. However, I accept that stricter parsing of the length fields is a good idea.

Regarding chunk extensions, these are ignored and not exposed to the user. Therefore, I don't believe it would be valuable to validate these. Feel free to correct me here.

Actions

• Adopt stricter parsing of the content length field according to the RFC.
• Adopt stricter parsing of the chunk length according to the RFC.
• Explicitly ignore any chunk extension fields.

Types of Changes

• Security

Contribution

• I added tests for my changes.
• I tested my changes locally.
• I agree to the Developer's Certificate of Origin 1.1.