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

httpResponseReceived.body() returns everything that follows a HTTP/1.1 100 Continue header as the body

Zac | Last updated: Apr 17, 2024 08:47AM UTC

In a recent Burp update, httpResponseReceived.body() now breaks if the response starts with HTTP/1.1 100 Continue. The following is an example: HTTP/1.1 100 Continue HTTP/1.1 200 Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, HEAD, POST, TRACE, OPTIONS, PUT, DELETE, PATCH httpResponseReceived.body() returns the following as the body(): HTTP/1.1 200 Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, HEAD, POST, TRACE, OPTIONS, PUT, DELETE, PATCH Further tests show that any of the httpResponseReceived.methods that reference individual data from the response are all broken if HTTP/1.1 100 Continue is used. The logic is technically correct. The issue here is that the HTTP/1.1 100 Continue header is a valid according to the http rfc spec (https://greenbytes.de/tech/webdav/rfc2616.html#use.of.the.100.status). The logic within burp should adhere to the http rfc spec and account for HTTP/1.1 100 Continue headers instead of everything after HTTP/1.1 100 Continue being taken as the body().

Hannah, PortSwigger Agent | Last updated: Apr 18, 2024 07:50AM UTC

Hi. You mention that this behavior has changed. Could you tell me the version of Burp that this was last working in for you? To clarify, the "100 Continue" response is being ignored, in favour of the "200" response? Just to double-check I'm understanding this correctly - would you be expecting multiple responses back from a single request, or would you expect the two responses to be concatenated together, like in the first example?

Zac | Last updated: Apr 19, 2024 04:44PM UTC

Hi Hannah, After further investigation it turns out that this is something never supported by Burp. The app I'm looking at only adds this on the mobile device version. I've got around it by creating a match/replace rule to remove Expect: 100-continue from the request. Then the response is "normal" (doesn't start with HTTP/1.1 100 Continue). This is a "hacky" way around the issue. Ideally, Burp would need to understand that the request header Expect: 100-contnue would result in a HTTP/1.1 100 Continue in the response and should parse the response accordingly (that body() is not everything following HTTP/1.1 100 Continue). To answer the question about multiple responses: These streamed responses (like Chunked Encoding which is what this app uses under the hood) is abstracted from Burp. Burp automatically streams these requests/responses in memory and then presents the tester with the final put together version. I previously confused the Expect: 100-continue request header with a streamed response. After referring to the rfc I have been enlightened and now understand this header to simply be a soft "check" to see if the server is available to respond, based on the following taken from the previously linked rfc: "The purpose of the 100 (Continue) status (see Section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body."

Hannah, PortSwigger Agent | Last updated: Apr 22, 2024 12:22PM UTC