search

PortSwigger / http-request-smuggler

https://portswigger.net/blog/http-desync-attacks
Other
952 stars 101 forks source link

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

Open Tib3rius opened 1 year ago

Tib3rius commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.