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

Confirming Client-Side Desync Results in Burp Scan Report

Scott | Last updated: Jun 28, 2024 01:04PM UTC

I ran a BURP scan and the client-side desync was detected. I'm having trouble understanding the confirmation logic in a Burp Scan report. I have read the James Kettle article as well as performed the Portswigger lab for the client-side desync. I understand the gist of the attack, but i'm just having trouble understanding how the data in the report is confirmation that the attack was successful. The confidence level is also tentative, which makes me question whether this was actually successful. The report says 'To verify this finding, review the response to 'Request 2' to identify whether it was influenced by the smuggled request.' but it's not clear to me what that means. In my report, 'Response 1' and 'Response 2' are identical, which doesn't seem right to me if this was successful. What would a successful attack look like in the report? Using an example, if my 'Request 1' looks like this (a POST request is made and a 2nd request is embedded in the POST body, so two requests are contained in the same single request): POST /abc123.js HTTP/1.1 Host: example.com Connection: keep-alive Content-Length: 367 GET /xyz456 HTTP/1.1 Host: example.com Connection: keep-alive Should Response 1 contain the response data from 2nd request embedded in the POST body (the GET /xyz456 HTTP/1 embedded request)? Another way of putting it, should the 'Response 1' data look exactly like I went to /xyz456 directly and didn't try to manipulate the connection. In my 'Request 2', I see an identical request attempt to 'Reqeust 1', but there is no 2nd request inside the body and it's using a GET instead of POST. Reqeust 2 looks like: GET /abc123.js HTTP/1.1 Host: example.com Connection: keep-alive Content-Length: 367 My assumption is that 'Request 2' is the 'control' test so you can see an unmanipulated response for what 'Request 2' is supposed to look like. You then compare 'Response 1' and 'Response 2' and if they are different, you know the attack was successful. Is that correct? If 'Response 1' and 'Response 2' are identical, would that mean this is a false positive?

Syed, PortSwigger Agent | Last updated: Jul 01, 2024 08:22AM UTC

Hi Scott,

Thank you for your message!

HTTP request smuggling leverages the differences in how web servers handle HTTP request headers. Specifically, it targets the Content-Length and Transfer-Encoding headers, which indicate the length of the HTTP message body. When these headers are manipulated, servers might process the request differently, causing desynchronization between the front-end (proxy) and back-end servers.

Example Scenario
Consider a scenario with a front-end proxy server and a back-end application server:

Normal Request Handling:
  • The client sends a request to the proxy server.
  • The proxy server forwards the request to the back-end server.
  • The back-end server processes the request and sends the response back to the client via the proxy.

HTTP Request Smuggling Attack:
  • The attacker crafts a malicious request with conflicting Content-Length and Transfer-Encoding headers.
  • The front-end proxy server interprets the request in one way (e.g., using the Transfer-Encoding header), while the back-end server interprets it differently (e.g., using the Content-Length header).

Detailed Example

Attacker's Malicious Request:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: vulnerable-website.com


Front-End Proxy Interpretation:
  • The proxy sees Transfer-Encoding: chunked and processes the request as chunked.
  • It interprets 0 as the end of the request body and forwards the remaining part (GET /admin HTTP/1.1) as a new request to the back-end server.

Back-End Server Interpretation:
  • The back-end server uses the Content-Length: 13 header to determine the length of the request body.
  • It processes the POST request with a body of 0\r\nGET /admin and treats GET /admin HTTP/1.1 as a separate request.


Differences in Response

Normal Response:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 123

(HTML content for /home)

Smuggled Response:

First Response (to the POST request):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 45

(HTML content indicating the POST request is processed)

Second Response (to the smuggled GET request):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 67

(HTML content for /admin)


Explanation of Differences

Normal Request Processing:
  • The server processes each request individually as expected.
  • The response corresponds directly to the requested resource.

Smuggled Request Processing:
  • The front-end proxy interprets the malicious request as two separate requests due to the smuggled content.
  • The back-end server also processes what it thinks are two legitimate requests.
  • The first response is for the POST / request, which may be benign or cause minor disruptions.
  • The second response is for the GET /admin request, which could expose sensitive information or unauthorized content.


I hope this makes sense. I can only give you an idea or explain how this works but doing a false positive analysis is out of the scope of my technical support duties. Based on this explanation and your own false positive analysis, if you think that the issue is most likely a false positive, then you can mark it as false positive and it won't be shown in the report of the scan.

Scott | Last updated: Jul 10, 2024 04:11PM UTC

I think I understand your response, but in terms of what the BURP scan report looks like for a Client Side Desync, Response 1 and Response 2 should NOT be identical if the attack was successful, correct? If Response 1 and Response 2 are identical, that would indicate a false positive?

Syed, PortSwigger Agent | Last updated: Jul 12, 2024 01:04PM UTC