Burp Suite User Forum

Login to post

wrong linefeed under macOS is breaking the Accessibility APIs

G. | Last updated: Jun 03, 2022 09:19AM UTC

the linefeed under macOS should be `\n`. Burp seems to be enforcing the Windows linefeed, `\r\n`. that breaks the macOS Accessibility as it returns a length of 2 characters while `\r\n\` is actually one character. is there any way in Burp to enforce the linefeed to be the macOS standard? thanks.

Liam, PortSwigger Agent | Last updated: Jun 03, 2022 10:19AM UTC

Thanks for this report. We'll discuss this with our Burp Pro product team and get back to you.

G. | Last updated: Jun 03, 2022 05:28PM UTC

thank you Liam! i've checked through the Preferences but couldn't find anything. any help is appreciated.

Michelle, PortSwigger Agent | Last updated: Jun 06, 2022 09:16AM UTC

Are you using the Repeater tool when you're seeing this issue? If you are, then if you click on the \n icon at the top of the request window you can display the non-printable characters and delete individual non-printable characters if this would help. If that's not quite what you're looking for can you send a few screenshots to help describe your scenario to support@portswigger.net, please? We can then take a closer look at what options are available for you.

G. | Last updated: Jun 10, 2022 06:12PM UTC

hi Michelle! yes, this is what i'm talking about, and this is what i've done as a test. but that would be pretty cumbersome to remove the \r character for each line manually. there's no option anywhere in Burp to choose the encoding? is there maybe any plan to add something? thanks.

Michelle, PortSwigger Agent | Last updated: Jun 13, 2022 10:28AM UTC

Thanks for the update. The use of /r/n comes from the HTTP/1 specification rather than being related to the OS-specific delimiter. Can you tell us more about the task you're carrying out? Are you using Burp's message editor? Are you using dictation or a screen-reader?

G. | Last updated: Jun 15, 2022 07:36AM UTC

> The use of /r/n comes from the HTTP/1 specification rather than being related to the OS-specific delimiter. ha! that makes total sense, my bad. > Can you tell us more about the task you're carrying out? Are you using Burp's message editor? Are you using dictation or a screen-reader? i build an app that adds Vim moves all over macOS. technically it does act like a screen reader yes. if it was only reading/writing the full value of a field, i could replace the `\r\n` by `\n`, but unfortunately i need a lot more information to calculate and generate a Vim moves. that includes line number, line range, etc. this is where it fails with Burp, because the AX API returns wrong lengths. but you made a good point regarding the HTTP/1 specification. so this is not a Burp's issue, this is on Apple and my app. thanks again for all the help. i think as far as Burp is concerned, there is indeed not issue on your side and this thread can be marked as resolved.

You need to Log in to post a reply. Or register here, for free.