Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Missing linebreak makes response unavailable in proxy\repeater

mr | Last updated: Dec 22, 2022 11:06AM UTC

Missing linebreak makes response unavailable while using a repeater or proxy. Probably for other features as well. Details: While testing an internal written webserver app i discovered some requests are marked as "timedout" while browsing using burp proxy. After some testing i narrowed it down to a single line break. Steps to reproduce: 1) Run a simplest possible webserver, using this command(this is for macos\bsd `nc`, flags may be a bit different for linux one): `echo -e "HTTP/1.1 200 OK\nRandomHeader: Value\n" | nc -l 3333` 2) Create a new tab in repeater and make any http call to localhost:3333. 3) Get a response "HTTP/1.1 200 OK\nRandomHeader: Value\n\r\n\r\n" (also, why those \r\n\r\n is there?) 4) So far so good, we received expected response and can see it in a response view. 5) Remove last linebreak: `echo -e "HTTP/1.1 200 OK\nRandomHeader: Value" | nc -l 3333` 6) Make another request from repeater 7) No response received and nothing to see in a response view. In a logger++ you can see request failed with a timeout, while it fails immediately --- I've asked a few friends to test it and everyone can confirm it fails with this kind of response. I know that technically it's not a valid http response, but: 1) It should not fail the proxy and repeater 2) It works perfectly in any modern browser and curl have no issue reading it as well 3) You can fire up wireshark and confirm that burp do receive the response, but failed to proceed with it

Michelle, PortSwigger Agent | Last updated: Dec 22, 2022 04:51PM UTC

Thanks for your message. If I understand your request correctly, you'd like Burp to handle responses that are not, strictly speaking, valid responses because if a normal browser encountered them it would work? To help us get a better understanding of your requirements, can you tell us more about the uses cases/scenarios where this would be useful and how frequently you are in a situation where you need Burp to handle this kind of response?

mr | Last updated: Dec 22, 2022 08:29PM UTC

Yes, you get it right. But, examples i provided is just narrowed down so it's easy to test and reproduce. However, i faced the actual issue with a already-in-production hardware device accessible over wifi and designed specifically to be accessible in the normal browser. And it does. But it doesn't work though burp proxy. While it's clearly a device(software) issue, i would like burpsuite to handle cases like this, since there is a quite a lot of home-made webservers in the world with all kind of weird issues and bugs. Here goes full (only sens info was cleaned) response i receive and burp have issues with. Dump from xdd, so you can reproduce it byte by byte: https://pastebin.com/Tx2V2h7A You can run in the same way `cat response | nc -l 3333` Just to clarify i see this issue as a bug report, not a feature request.

mr | Last updated: Jan 03, 2023 12:24PM UTC

Hello. Did you have a time to reproduce the issue and look into it? Thanks.

Michelle, PortSwigger Agent | Last updated: Jan 04, 2023 12:14PM UTC

We did reproduce this and have logged it in our system. It's not something other customers have raised with us before, so we'll be monitoring how many people are affected as we prioritize our work. We've linked this thread so we can post back here with any updates.

sohail | Last updated: Jan 04, 2023 01:40PM UTC