Hey everyone! Check out this playlist for all my solutions to the HTTP Request Smuggling labs from PortSwigger - 👀 th-cam.com/play/PLGb2cDlBWRUX1_7RAIjRkZDYgAB3VbUSw.html Here are the timestamps for this video - ⏱ 00:00 - Intro 00:28 - Explore the lab 00:43 - Prepare Repeater for Request Smuggling 01:52 - Detect what the frontend is using 02:41 - Detect what the backend is using 03:10 - Detect the TE header obfuscation vulnerability 04:22 - Confirm the TE header obfuscation vulnerability 06:26 - Craft and send the final payload
thanks a mil @panchakosha, glad to hear that image is helpful! I learned the methodology from James Kettle's "HTTP Desync Attacks" paper, it's a fantastic resource: portswigger.net/kb/papers/z7ow0oy8/http-desync-attacks.pdf
Hello Jarno! Thank you for the explanatory video. You helped me much, understanding the request smuggling! Please allow me two questions: - Portswigger refers to this lab as the TE.TE lab (TE.TE behavior: obfuscating the TE header). If I understood correctly, in cases where both CL and TE headers are present, TE is always given preference. Therefore, it's unclear why the backend server "switches" to CL if it receives a valid TE header. Or is it the frontend that switches to CL? I'm a bit confused. - This question is similar to the previous one. If the backend receives two TE headers, one of which is a valid TE header, why doesn't it use that instead of switching to CL? Thank you for the answers!
hey @Omega182, glad it was helpful! 🔥 in the case of this lab, by adding a second Transfer-Encoding header with an invalid value of foobar, we find that the frontend server is more lenient and instead of rejecting the Transfer-Encoding headers entirely, it still processes the first Transfer-Encoding: chunked header and treats the request as chunked. But the backend server is less lenient, and rejects the Transfer-Encoding headers. That could either be because there are two Transfer-Encoding headers, and/or because one of them is invalid as it has the value "foobar" instead of chunked. So essentially we turned this lab from a TE.TE lab into a TE.CL lab.
Hey everyone! Check out this playlist for all my solutions to the HTTP Request Smuggling labs from PortSwigger - 👀
th-cam.com/play/PLGb2cDlBWRUX1_7RAIjRkZDYgAB3VbUSw.html
Here are the timestamps for this video - ⏱
00:00 - Intro
00:28 - Explore the lab
00:43 - Prepare Repeater for Request Smuggling
01:52 - Detect what the frontend is using
02:41 - Detect what the backend is using
03:10 - Detect the TE header obfuscation vulnerability
04:22 - Confirm the TE header obfuscation vulnerability
06:26 - Craft and send the final payload
Great explanation. That detect image is really useful. I've learned to solve all HRS labs on portswigger manually using a similar methodology.
thanks a mil @panchakosha, glad to hear that image is helpful! I learned the methodology from James Kettle's "HTTP Desync Attacks" paper, it's a fantastic resource:
portswigger.net/kb/papers/z7ow0oy8/http-desync-attacks.pdf
can i get the slide
Hello Jarno! Thank you for the explanatory video. You helped me much, understanding the request smuggling! Please allow me two questions:
- Portswigger refers to this lab as the TE.TE lab (TE.TE behavior: obfuscating the TE header). If I understood correctly, in cases where both CL and TE headers are present, TE is always given preference. Therefore, it's unclear why the backend server "switches" to CL if it receives a valid TE header. Or is it the frontend that switches to CL? I'm a bit confused.
- This question is similar to the previous one. If the backend receives two TE headers, one of which is a valid TE header, why doesn't it use that instead of switching to CL?
Thank you for the answers!
hey @Omega182, glad it was helpful! 🔥
in the case of this lab, by adding a second Transfer-Encoding header with an invalid value of foobar, we find that the frontend server is more lenient and instead of rejecting the Transfer-Encoding headers entirely, it still processes the first Transfer-Encoding: chunked header and treats the request as chunked.
But the backend server is less lenient, and rejects the Transfer-Encoding headers. That could either be because there are two Transfer-Encoding headers, and/or because one of them is invalid as it has the value "foobar" instead of chunked.
So essentially we turned this lab from a TE.TE lab into a TE.CL lab.
You can leave out the Content-Type header in requests as well.
In my case I did it this way Transfer-Encoding: Xchunked
Transfer-Encoding chunked
0
r
G and it worked.