Client Side Desync
In high-level terms, a CSD attack involves the following stages:
The victim visits a web page on an arbitrary domain containing malicious JavaScript.
The JavaScript causes the victim's browser to issue a request to the vulnerable website. This contains an attacker-controlled request prefix in its body, much like a normal request smuggling attack.
The malicious prefix is left on the server's TCP/TLS socket after it responds to the initial request, desyncing the connection with the browser.
The JavaScript then triggers a follow-up request down the poisoned connection. This is appended to the malicious prefix, eliciting a harmful response from the server.
As these attacks don't rely on parsing discrepancies between two servers, this means that even single-server websites may be vulnerable.
Probing the request:
simplest way to probe for this behavior is by sending a request in which the specified Content-Length is longer than the actual body:
If the request just hangs or times out, this suggests that the server is waiting for the remaining bytes promised by the headers.
If you get an immediate response, you've potentially found a CSD vector. This warrants further investigation.
As with CL.0 vulnerabilities, we've found that the most likely candidates are endpoints that aren't expecting POST requests, such as static files or server-level redirects.
Last updated