PortSwigger / http-request-smuggler

https://portswigger.net/blog/http-desync-attacks
Other
946 stars 103 forks source link

Questions about "Gzip request body" #66

Open rcbarnett opened 3 months ago

rcbarnett commented 3 months ago

@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. image

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

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. image

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

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 commented 3 months ago

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: https://github.com/PortSwigger/http-request-smuggler/blob/75a40815a944391bfbefe9c8b70faec1fae3ea21/src/burp/SmuggleScanBox.java#L176-L182

rcbarnett commented 3 months ago

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.