[io]: HTTP header parser incorrectly accepts NUL within header values

[kenballus]

From RFC 9110:

Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message.

dart:io does not enforce this rule for NUL. You can see this by running a simple example that echoes back header values (such as this), and sending it a request containing NUL within a header value:

printf 'GET / HTTP/1.1\r\nHost: whatever\r\nTest: \x00\r\n\r\n' \
  | timeout 1 ncat --no-shutdown localhost 80 \
  | grep '"headers"' \
  | jq '.["headers"][0][1]' \
  | xargs echo \
  | base64 -d \
  | xxd

00000000: 00                                       .

$ dart info
...
- Dart 3.6.0-edge.3cc6105316be32e2d48b1b9b253247ad4fc89698 (main) (Fri Aug 30 22:53:32 2024 +0000) on "linux_x64"
- on linux / Linux 6.10.2-arch1-2 #1 SMP PREEMPT_DYNAMIC Sat, 03 Aug 2024 17:56:17 +0000
- locale is en_US

[dart-github-bot]

Summary: The dart:io HTTP header parser incorrectly accepts NUL characters within header values, violating RFC 9110 which mandates rejection or replacement of such characters. This vulnerability could lead to unexpected behavior or security risks.

[lrhn]

Tentatively marking as dart:io-related. Maybe it's in dart:_http.

[brianquinlan]

I did some research here into different client (I realize that this is a server issue but dart:io should be consistent with its client and server header handling):

Client	NUL	CR/LF
Chrome	Reject	Treat as end-of-header
dart:io	Preserve	Reject
cronet	Reject	Treat as end-of-header
Apple NSURLSession	Preserve	Treat as end-of-header

So probably the right thing to do here is reject the request like Chrome and Cronet do.