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

Burp is capitalizing the Headers, which breaks some implementations

Alexandre | Last updated: Aug 09, 2021 02:17PM UTC

I realized that when proxying though burp the headers are forwarded capitalized. Ex.: The OPTIONS request returns "Access-Control-Allow-Headers: x-accesstoken" The request in the browser contains the token in "x-acesstoken" header, but when passing though burp the request goes with "X-Acesstoken". This triggers a HTTP/1.1 401 Unauthorized response.

Uthman, PortSwigger Agent | Last updated: Aug 10, 2021 09:03AM UTC

Hi Alexandre, Thank you for reporting this. Can you please share the information below with support@portswigger.net? - Replication steps (ideally a screen recording) and diagnostics (Help > Diagnostics) - Does the issue occur on all sites? Can you replicate it on https://portswigger-labs.net? - Are you adding a custom header in Burp? If so, how? Are you using an extension? - Please share a screenshot of the Developer tools > Network tab in a browser both configured to work with and without Burp. This will need to capture the request you are referring to (e.g. one that includes the x-accesstoken header) - Are you working with an HTTP/1.1 request? Or an HTTP/2 one? - If you look at the headers in the Inspector, are they showing what you would expect to see? Can you share a screenshot of this?

Uthman, PortSwigger Agent | Last updated: Aug 10, 2021 01:59PM UTC

For anyone else experiencing this issue, I have done some testing and you will need to check if HTTP/2 is disabled under Project options > HTTP > HTTP/2 but it is still enabled on the Proxy listener (Proxy > Options > select a listener > Edit > HTTP > HTTP/2). If you disable HTTP/2 in both places, the issue will not occur. I appreciate that this can be confusing but our developers have explained why this occurs: 1: An HTTP1.1 request in curl (with a lowercase header) 2: Curl connects to burp and finds out that burp supports HTTP2 3: Curl converts the HTTP1.1 request into an HTTP2 request. (Lowercasing ALL the headers and doing other HTTP2 stuff) 4: Curl sends this new HTTP/2 request to burp 5: Burp gets the request in HTTP/2 format 6: Burp sees that HTTP/2 is disabled for the application 7: Burp converts the HTTP/2 request into HTTP1.1 format. Uppercasing all the headers 8: Burp forwards that to the HTTP 1.1 only application

Jürgen | Last updated: Feb 15, 2023 04:38PM UTC

I just had problems with this behaviour as well. One thing to note here is that the uppercasing in step 7 (and therefore this quirk) should not be necessary. RFC9110 (and RFC7230 before that) explicitly states that field names are case-insensitive. So I don't think Burp should unnecessarily change inputs, at least for non-standard headers.

Hannah, PortSwigger Agent | Last updated: Feb 17, 2023 02:23PM UTC