Questions about "Gzip request body"

[rcbarnett]

@albinowax - per my question on X - I am testing the http request smuggler menu option to "Gzip request body" and I have a few questions.

Example usage: I have a normal urlencoded request body with a POST method.

Once this has executed, the body is Gzip compressed and a Transfer-Encoding: gzip header is added.

My first question is why Transfer-Encoding is used instead of Content-Encoding? TE is a hop-by-hop header whereas CE would be kept along the pipeline path as it is specifically related to the compressed body content.

My second question is that there might be a possible bug in relation to the compression itself. If I "turn on non printable characters" option, I see the compressed body header begins with the expected "1F8B" characters that indicate Gzip compression.

If, however, I switch to "Hex" view, you will see that there is a "c2" character in between:

Is this a bug in the implementation? I am asking as the gunzip mechanisms are not working on these bodies. You can test using that exact payload and gzip commandline:
$ gzip -t -v /tmp/3 gzip: /tmp/3: not in gzip format /tmp/3: NOT OK

$ od -c /tmp/3 0000000 037 302 213 \b 001 001 001 001 001 001 ÿ ** K Î ** M 0000020 ± ** M H N , Q Ð ** O - I Ö ** / H 0000040 , . . O I 001 001 * \ A 036 025 001 001 001 \n 0000060
Is this a bug in the gzipBody() function code or is this expected? Are there perhaps lax parsers that can still gunzip these bodies?

[albinowax]

Good questions! It's been a few years but think I used Transfer-Encoding deliberately over Content-Encoding, as I wanted the front-end to transform the request.

Regarding the mystery c2, that is definitely not intentional. I'm not sure if it's being caused by an issue in Burp itself, or bad bytes/string conversion here:

http-request-smuggler/src/burp/SmuggleScanBox.java

Lines 176 to 182 in 75a4081

	byte[] req = Utilities.addOrReplaceHeader(baseReq, "Transfer-Encoding", "gzip");
	String body = Utilities.getBody(req);
	ByteArrayOutputStream out = new ByteArrayOutputStream();
	GZIPOutputStream gzip = new GZIPOutputStream(out);
	gzip.write(Utilities.helpers.stringToBytes(body));
	gzip.close();
	return Utilities.setBody(req, Utilities.helpers.bytesToString(out.toByteArray()));

[rcbarnett]

Thanks for the quick reply. I suppose the use of Transfer-Encoding vs. Content-Encoding depends on your use case and goals for the tests and why you are using compression for the request body content.

As for the mystery c2, yeah it was a a bit tricky troubleshooting to figure out why gzipped request bodies weren't gunzipping correctly. I just wanted to alert you to this issue as there may be other Burp users using this Extension and their tests aren't working.

FYI - I have worked with many customers who were testing/triaging Request Smuggling/Desync bug reports so I am quite familiar with this extension. There is often confusion around how to properly craft Desync PoCs.