Bytes `>=0x80` are stripped from the beginnings and ends of header values

[kenballus]

What version of Bun is running?

1.0.26-debug+7405c5a61

What platform is your computer?

Linux 6.7.2-arch1-2 x86_64 x86_64

What steps can reproduce the bug?

1. Start a Bun web server that shows you each received request's message body, e.g. by running this script.
2. Send it a request containing bytes greater than or equal to 0x80 on either side of a header value:

printf 'GET / HTTP/1.1\r\nHost: whatever\r\nKey: \xffvalue\xff\r\n\r\n' | nc localhost 80

What is the expected behavior?

Bun should provide a response indicating that it received a header with the name Key (case-insensitive), and the value \xffvalue\xff.

What do you see instead?

Bun's response indicates that it stripped the \xff bytes from the header value. To see this for yourself, run the reproduction steps, and then run the following command:

printf 'GET / HTTP/1.1\r\nHost: whatever\r\nKey: \xffvalue\xff\r\n\r\n' | nc localhost 80 | tail -n 1 | jq '.["headers"][1][1]' | sed 's/"//g' | base64 -d | hexdump -C

You should see output that looks like this:

00000000  76 61 6c 75 65                                    |value|
00000005

This demonstrates that the \xff bytes have been stripped.

Additional information

It is very likely that this bug can be used to execute request smuggling attacks when Bun is deployed behind certain HTTP gateway servers by sending Transfer-Encoding: \xffchunked\xff headers.

[Jarred-Sumner]

Are non-ascii characters valid in HTTP headers? Maybe instead of removing them, we should replace them with a different character

[kenballus]

Non-ASCII characters are valid in HTTP header values. See RFC 9110, section 5.5.

[kenballus]

The only restrictions on HTTP header values are that they must not contain null bytes, carriage returns, or line feeds. If a header is received containing any of those bytes, the server must either replace them with spaces, or reject the message.

[AlttiRi]

Using of UTF-8 bytes as a "Binary" string in a "Content-Disposition" header is a common old thing.
You only need to convert "BinaryString" to a common "String" when you parse it manually.
All browsers do it automatically, for example, click on this: https://web.archive.org/https://download1084.mediafire.com/z7j89kwbqrzg/gphbkhjqqx8aesq/✅⏳🔥💧.txt
a browser will download "✅⏳🔥💧.txt" file. "Content-Disposition" header here is bytes of a string encoded in UTF-8.

JS demo:

const url = "https://web.archive.org/https://download1084.mediafire.com/z7j89kwbqrzg/gphbkhjqqx8aesq/✅⏳🔥💧.txt";
const headerValue = (await fetch(url)).headers.get("Content-Disposition");
console.log(headerValue);
console.log(bStr2Str(headerValue));

function bStr2Str(bString) {
    return new TextDecoder().decode(binaryStringToArrayBuffer(bString));
}
function binaryStringToArrayBuffer(binaryString) {
    const u8Array = new Uint8Array(binaryString.length);
    for (let i = 0; i < binaryString.length; i++) {
        u8Array[i] = binaryString.charCodeAt(i);
    }
    return u8Array;
}

function str2BStr(string) {
    return arrayBufferToBinaryString(new TextEncoder().encode(string));
}
function arrayBufferToBinaryString(arrayBuffer) {
    return arrayBuffer.reduce((accumulator, byte) => accumulator + String.fromCharCode(byte), "");
}

However, Bun works OK with with demo too on Windows:

[kenballus]

I have tested only that the bytes in /[\x80-\xff]/ are stripped when Bun is acting as a server.

I think what you've demonstrated is that this is server-specific behavior, and that it doesn't have the same problem when acting as a client, right?