Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp would change hex values of non-printable characters in binary files in POST request (repeater/intercept)

Paweł | Last updated: Sep 02, 2024 08:02PM UTC

Hi, I'm on version v2024.7.5 I encountered bug in intercept and repeater. When editing POST request that has attached in body binary file like xls. After modyfing as little as one character in "pretty" and "raw" tab in request e.g in header "cookies" whole request changes "encoding" and binary file have different hex values for non-printable characters. I will paste only few lines of request to not clobber whole page So this is part of the request where headers ends and content-disposition starts and where file also starts ``` 61 3B 20 6E 61 6D 65 3D 22 66 69 6C 65 22 3B 20 66 69 6C 65 6E 61 6D 65 3D 22 69 6D 70 6F 72 74 5F 70 72 6F 6A 65 63 74 78 2E 78 6C 73 22 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 6D 73 2D 65 78 63 65 6C 0D 0A 0D 0A D0 CF 11 E0 A1 B1 1A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 00 03 00 FE FF 09 00 06 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 10 00 00 02 00 00 00 01 00 00 00 FE FF FF FF 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ``` it coresponds to ``` a; name="file"; filename="import_projectx.xls" Content-Type: application/vnd.ms-excel ÐÏࡱá ``` so most of this are unprintable characters Now I will modify cookie header of this request in "pretty" or "raw" tab And this is how looks like end of headers and starts of binary files. ``` 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 6D 73 2D 65 78 63 65 6C 0D 0A 0D 0A EF BF BD EF BF BD 11 E0 A1 B1 1A EF BF BD 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 00 03 00 EF BF BD EF BF BD 09 00 06 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 10 00 00 02 00 00 00 01 00 00 00 EF BF BD EF BF BD EF BF BD EF BF BD 00 00 00 00 00 00 00 00 EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF ``` FF values are replaced with BF values Modifying values in "hex" tab works as expected

Michelle, PortSwigger Agent | Last updated: Sep 03, 2024 03:13PM UTC

Thanks for getting in touch to report the issue. I have replicated the issue when intercepting requests via Burp Proxy. Can i check a few details with you about the requests in Repeater? If you send a request to Repeater and just send it without any changes, does it send successfully? If you then try to send it again from the same Repeater tab, do you see the same problem as you do when you edit it before sending?

Paweł | Last updated: Sep 03, 2024 04:20PM UTC

Hi, yes in repeater if I send it without editing it is send successfully. When I try to send it again even without modyfing POST body is changed.

Michelle, PortSwigger Agent | Last updated: Sep 04, 2024 08:39AM UTC

Hi Thanks for the update. I have replicated the issues you have reported with the repeater tab and have rasied bug reports for what you are seeing in Proxy Intercept and Repeater. The developers will need to perform some further checks on these so we can priortize them alongside other bugs and requests. Thank you for taking the time to report the issues.

dec1m0s | Last updated: Sep 09, 2024 11:24AM UTC

In addition to what has already been reported, I would like to add that sending the same request twice in the Repeater tab without any changes will change the encoding. This can be seen by the Content-Length header suddenly increasing after the request has been sent. As a workaround, I can use the Hackvertor view to edit requests with non-printable characters in the body, as this doesn't seem to change the encoding. However, this is not optimal due to the lack of syntax highlighting. It would be great if this bug could be fixed as soon as possible.

Michelle, PortSwigger Agent | Last updated: Sep 09, 2024 01:55PM UTC

Hi Can you please confirm which version of Burp you are using? Also, can you tell us more about the request you are editing? Does it contain any images or files? What part of the request are you editing?

dec1m0s | Last updated: Sep 12, 2024 05:47AM UTC

I am using Burp Suite Professional 2024.7.5 (build 31789). The request I was referring to was a multipart/form-data request to upload a PDF document containing non-printable characters in the request body. I opened the request in the Repeater tab and tried to send it several times without any changes. The first time I sent the request, everything worked fine and I received a valid response. But as soon as I sent it again (without any changes!), the Content-Length header increased and the server couldn't process the response. Confused by this behaviour, I switched to the Logger tab and copied both requests into the Comparer. There I discovered that the request body had been modified, in particular that the non-printable characters had been encoded differently.

Michelle, PortSwigger Agent | Last updated: Sep 12, 2024 08:17AM UTC

Hi Thanks for the update. This matches a bug that our developers have been working on, so a fix for this should be available soon. Thanks for taking the time to report it :)

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.