Skip to content

fix: reject whitespace between chunk-size digits - #1257

Open
pjfanning wants to merge 1 commit into
apache:mainfrom
pjfanning:reject-chunk-size-interior-whitespace
Open

fix: reject whitespace between chunk-size digits#1257
pjfanning wants to merge 1 commit into
apache:mainfrom
pjfanning:reject-chunk-size-interior-whitespace

Conversation

@pjfanning

Copy link
Copy Markdown
Member

Motivation

The chunked-body parser tolerates whitespace after the chunk-size digits (illegal per RFC 7230 but seen in the wild — see #1812), but the WSP arm recursed with the same accumulated size and then let parsing continue with the next character, including a further hex digit:

case c if CharacterClasses.HEXDIG(c)   => parseSize(cursor + 1, size * 16 + CharUtils.hexValue(c))
...
case c if CharacterClasses.WSP(c) => parseSize(cursor + 1, size) // see issue #1812

So a chunk size of 5 0 was parsed as 0x50 = 80 bytes, whereas a proxy that stops at the space reads 5. That size discrepancy is a request-smuggling primitive when Pekko HTTP sits behind such a proxy. The #1812 comment intended only trailing whitespace tolerance; the code skipped interior whitespace as well. The WSP arm also lacked a cursor > offset guard, so a size field of only spaces parsed as 0.

Modification

Thread a sawWhitespace flag through parseSize:

  • Once whitespace has been seen, the hex-digit accumulation arm is guarded off (HEXDIG(c) && !sawWhitespace), so a subsequent hex digit falls through to the illegal-character case — only more whitespace or a terminator (;, CRLF, LF) may follow.
  • The WSP arm now requires cursor > offset, so leading whitespace before any digit is rejected too.

Trailing whitespace after a complete size is unchanged (still tolerated).

Result

5 0 and 5 are now rejected with Illegal character '...' in chunk start, while 5<SP><SP>\r\n (trailing BWS) still parses. Pekko HTTP and a fronting proxy can no longer disagree on the chunk size.

Tests

  • sbt "http-core/testOnly org.apache.pekko.http.impl.engine.parsing.RequestParserCRLFSpec org.apache.pekko.http.impl.engine.parsing.RequestParserLFSpec" — pass (116 tests). Two new tests reject 5 0 (interior whitespace) and 5 (leading whitespace); the existing "incorrect but harmless whitespace after chunk size" (#1812) test still passes. Verified the interior-whitespace test fails with the fix stashed (5 0 parses as 80 bytes).
  • sbt http-core/mimaReportBinaryIssues — pass (internal impl.engine.parsing change, no public API).
  • Native scalafmt on the changed files — clean.

References

Refs #1812 - narrows the whitespace tolerance to trailing whitespace only

🤖 Generated with Claude Code

Motivation:
The chunk-size parser tolerates whitespace after the size digits
(illegal per the spec but seen in the wild, see #1812), but the `WSP`
arm recursed with the same accumulated size and then let parsing
continue with the next character — including a further hex digit. So a
chunk size such as `5 0` was read as `0x50` = 80 bytes, while a proxy
that stops at the space reads 5. That discrepancy is a request-
smuggling primitive when Pekko HTTP sits behind such a proxy. The
comment referencing #1812 intended only trailing whitespace; the
implementation skipped interior whitespace too. The `WSP` arm also had
no `cursor > offset` guard, so a size field of only spaces parsed as 0.

Modification:
Thread a `sawWhitespace` flag through `parseSize`. Once whitespace has
been seen, a hex digit no longer matches the accumulation arm and falls
through to the illegal-character case, so only more whitespace or a
terminator may follow. Guard the `WSP` arm with `cursor > offset` so
leading whitespace (before any digit) is rejected as well.

Result:
Trailing whitespace after the chunk size is still tolerated, but
whitespace between size digits, and leading whitespace, are rejected
with "Illegal character '...' in chunk start" — Pekko HTTP and a
fronting proxy can no longer disagree on the chunk size.

Tests:
- sbt "http-core/testOnly org.apache.pekko.http.impl.engine.parsing.RequestParserCRLFSpec org.apache.pekko.http.impl.engine.parsing.RequestParserLFSpec" - pass (116 tests); two new tests reject `5 0` (interior whitespace) and ` 5` (leading whitespace), and the existing "incorrect but harmless whitespace after chunk size" test still passes. Verified the interior-whitespace test fails with the fix stashed (`5 0` parses as 80 bytes).
- sbt http-core/mimaReportBinaryIssues - pass (internal impl.engine.parsing change, no public API).

References:
Refs #1812 - narrows the whitespace tolerance to trailing whitespace only
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

Successfully merging this pull request may close these issues.

1 participant