Client-side desync issue detection seems to spit out false positives consistently.

[Tib3rius]

This has happened on almost every engagement I've used the scan on. I get an issue flagging "Client-side desync", which granted is marked "Tentative" but it seems like it should easily be detected as a false positive.

Both Response 1 and Response 2 are identical, despite the issue stating that the smuggled request in Request 1 is interpreted as the next request. It might be that the issue text is a little misleading or I'm not fully understanding the issue, but presumably if this were a Client-side desync, we would expect Response 2 to be the response from the smuggled request and not the actual Request 2?

If you need more info I can try to provide it, though so far I've only used this on real world targets so I would have to redact a lot of info.

[albinowax]

This scan identifies potential client-side desync vulnerabilities by sending a single request, and getting two responses. The two responses aren't expected to be different. You can find the details here: https://portswigger.net/research/browser-powered-desync-attacks#methodology

The way the requests are attached to the scan issue can be misleading; pay close attention to the content-length header. The second 'request' is actually the body of the first request.

[Tib3rius]

Thanks for the link, I'll read through it. I'm not quite sure I understand your last sentence though. The second request isn't the body of the first request for me, it's the first request except sent as a GET instead of a POST and lacking the POST-related headers.

I think I'll have to rewatch your talks on the subject a little more!

[albinowax]

Can you confirm what the Content-Length of the first request is set to? It should be above 0. It's possible some other extensions are 'correcting' the CL to 0, which could cause false positives.

[Tib3rius]

The Content-Length of Request 1 looks like it's set to 359. I can see the body of Request 1 is a GET request to a random resource on the server. The Response 1 body contains nothing but a standard PNG file which was the original result of Request 1 (i.e. prior to me scanning it).

Response 2 appears to be identical apart from the Connection header being set to close instead of keep-alive (in Response 1). Not sure if that's important? The body of Response 2 contains the same PNG as Response 1, whereas I presume we would expect the response from the smuggled request in Request 1?

If any of that is confusing I can try to sanitize the data to remove customer info and share it.