0x22bb
/
hacktricks
mirror of https://github.com/carlospolop/hacktricks.git
1
2
Fork 0
Code Releases Activity

GitBook: [master] one page and 3 assets modified

This commit is contained in:
CPol 2021-03-23 01:08:47 +00:00 committed by gitbook-bot
parent b37bc52e68
commit bf817b3e5b
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
4 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
.gitbook/assets/image (442).png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
.gitbook/assets/image (443).png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
.gitbook/assets/image (444).png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

10
pentesting-web/http-request-smuggling.md
View File

@ -124,10 +124,18 @@ Content-Length: 4
1
A
X`
0`
Since the front-end server uses the `Content-Length` header, it will forward only part of this request, omitting the `X`. The back-end server uses the `Transfer-Encoding` header, processes the first chunk, and then waits for the next chunk to arrive. This will cause an observable time delay.
Sometimes, instead of getting a timeout you receive a 400 bad request from the final host like in the following scenario, where a CL.TE payload is sent:
![](../.gitbook/assets/image%20%28444%29.png)
And the response is a redirect containing an error inside the body with even the version of the haproxy used:
![](../.gitbook/assets/image%20%28443%29.png)
### Finding TE.CL vulnerabilities using timing techniques
If an application is vulnerable to the TE.CL variant of request smuggling, then sending a request like the following will often cause a time delay: