Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp/Repeater decodes payload incorrectly

Daniel | Last updated: Sep 01, 2016 12:32PM UTC

I am trying to send different payloads with Burp repeater, but found some characters to result in unwanted behavior of the repeater functionality. Details: I am sending the following character as a repeater payload (does not matter weather URL or Body payload. Make sure you are in the "Params" tab of the repeater: “ Please note that this is _not_ a %22 char. Burp sends this out as \x1C, which is also not correct, as this is the Unicode char for "Left double quotation mark", see http://unicode-table.com/de/search/?q=%E2%80%9C After I post the request, not only the wrong char encoding is send out (\x1C), but this also messes up my repeater tab, as the char itself disappeared and another payload line shows. Seems like an encoding issue? Cheers, Daniel

PortSwigger Agent | Last updated: Sep 01, 2016 12:36PM UTC

Repeater operates on raw bytes, not characters. It is only possible to send a sequence of bytes in an HTTP request, and you cannot directly represent a special Unicode character within a single byte. You can represent a special character in a multi-byte sequence using a suitable character set, but you cannot send an HTTP request and use an extended character set directly within the request headers. The normal way that special characters are represented within HTTP requests is to use multi-byte URL-encoding, so you use %xx%yy to send a two-byte sequence that represents a character in the character set employed by the server-side logic. If you aren't sure, try UTF-8, and send the two-byte sequence for the character you want, and see if the application interprets it in the way you want.

Burp User | Last updated: Sep 01, 2016 12:46PM UTC

Gotcha, cheers. I though one could enter Unicode in the "value" field and repeater would automagically encode them correctly into multi-byte requests. Anyhow, this should not mess up the GUI/tab layout, should it?

PortSwigger Agent | Last updated: Sep 01, 2016 12:47PM UTC

The problem with trying to automagically encode is that although UTF-8 is a fairly safe guess, you don't really know what character set the server-side app is expecting or would tolerate. It's not completely clear why Burp ends up putting 0x1c into your request when you entered the character in question. However, in ASCII this represents a non-printing character (file separator) so you wouldn't expect the character to render as anything, and it might explain why the newline appears.

Burp User | Last updated: Sep 01, 2016 12:55PM UTC

Right, this explains it. When entering it in the decoder tab, it indeed results in 0x1c. Guess burp simply discards this and/or prints simply a newline. Handling multibyte is a mess, that's why so many web apps fail handling those properly :) Thanks for the clarification.

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