Carriage Return Being Stripped

[tzuk-pl]

Issue

Encountered an issue where the Carriage Return ASCII character (0d in hex, \r) is being stripped from matching lines causing malformed HTTP requests.

Below shows a sample CPH tab configured to replace an Authorization bearer header token that will currently result in a malformed HTTP request. This configuration previously worked. This issue appears to occur when the initial match (box 1) is intended to stop at the end of the line, such as when a header is being replaced.

Below is the final HTTP request sent after CPH replaces the bearer token. The cache-control header is the next header after thee bearer token. Note that the highlighted hex has the line ending character as a Line Feed (0a in hex) without a Carriage Return (0d in hex). HTTP requires both CRLF (0d 0a in hex, \r\n) for line endings.

Fix

I have not gone through the code however based on the behaviour observed I belieive the "Find matches to this expression" may now be terminating the line at the Line Feed character \n, capturing the \r in the replacement group, resulting in it being stripped from requests CPH modifies.

Workaround

The below screenshot shows the current workaround, append the Carriage Return in the "Replace each Target" field if you are getting HTTP 400 Bad Requests.

[elespike]

Thanks for the bug report! I'll have a look this week to hunt down which change caused this and restore the proper behavior.

[elespike]

@tzuk-pl, I went back all the way to the 3.0 RC1 release, and this behavior is still present there.

While I agree it's not intuitive and less than ideal, the behavior itself is correct:

• You're looking for .* at the end of the expression, which matches anything except a newline/line feed (0a), so your target match includes the carriage return, 0d.
• Then, you replace that with the token value enclosed in double quotes, which of course doesn't contain 0d.

Your workaround is the quickest way to go about this. Another way is to make your target match more strict; e.g., Authorization: Bearer [a-zA-Z0-9-_.]*, or Authorization: Bearer [^\r]* =p

Note that RegEx flags are available as well so you could, for example, match 0a with the s flag: https://github.com/elespike/burp-cph/wiki/10.-Enabling-RegEx-flags

I'll think about how to make this better.

[tzuk-pl]

Thanks for looking at this quickly! I'll be sure to note down the behaviour for future reference, I must have been doing something slightly different with my matching before to avoid matching \r. Thanks for the quick top as well.

Cheers

[elespike]

My pleasure! I'll keep this open for some time while I think about enhancements.