This was by far the most informative and "complex but simple" approach to explaining this topic I have come across. You are a great teacher my friend. Thank you!
It's been 3 hours of seeing videos about HTTP request smuggling and still didn't get it. But when I see yours wow ! That was smooth and easy to understand ! Thanks for the content and now I'm Subscriber to your channel. Keep it up man
I had some difficulties to get my head around http request smuggling. But you delivered a great mnemonic. I will associate Pizza ristorante with request smuggling forever.
Amazing video! Thank you for making it! Quick question, at 17:14, you set the Content-Length to 800. If the victim's request isn't that long, wouldn't that result in the smuggled request being timed-out? Thanks again 🙏
When you show TE/CL, the second chunk is 23, not 0 - so far so good. But since 23 is one character longer than 0, the header Content-Length should be changed from 10 to 11.
The request body where the robot.txt is found can I still modify the supposed request to smuggle from there immediately rather than smuggling the robot.txt????
Hey , probably best explanation on request smuggling, Thanks! However can you please clarify to me the use of "7f" in the request? And the 1 Z Q Any help is appreciated
Thank's for your feedback! When requests are sent with "Transfer-Encoding: chunked", we need to specify how many bytes we are sent like... 4 (--> 4 bytes are following) id=1 (--> this is our payload and has 4 bytes) 0 (--> zero bytes follow. This is the end of our request) In your second example, we defined an INVALID request to force a server into a timeout. 1 (--> 1 byte is following) Z (--> our payload. Could be anything else like A, B, C, D, 1, 2, 3, 4, etc) Q (--> here we would expect the next chunk length. So the request is INVALID, at least for chunked requests; this could be any other letter like A, B, C, D, etc) The chunk lengths are defined as hexadecimal numbers. 7f in your first example is 127 in decimal (see: coolconversion.com/math/binary-octal-hexa-decimal/_hex__7F_to_decimal_), this means 127 bytes follow. The payload then actually has a length of 127 bytes and the 0 in the next line means: chunked payload ends here.
@@mizo7627 I'm not sure I understand what you mean. But you will probably not be able to replace carriage return/newline because this is part of the http standard. You might want to give an example, what payload you are referring to and what you want to reach by replacing the characters.
GET /admin HTTP/1.1 foo: xGET / HTTP/1.1 host: innocent.com cookie:.... bro plz tell me how the server reads the second line(ie,foo:xGET..)? or it just ignore the line??
Do you have any feedback? Which vulnerabilities would you like me to explain in my next videos?
lfi
This was by far the most informative and "complex but simple" approach to explaining this topic I have come across. You are a great teacher my friend. Thank you!
This is the best explanation of http request smiggling I've ever seen! Great job!
The best explanation in terms of the exploitation, thanks a lot.
Thank you!! Very glad you liked it!
Nice explanations. I really like the exemple with the restaurant.
Thank you :-)
It's been 3 hours of seeing videos about HTTP request smuggling and still didn't get it. But when I see yours wow ! That was smooth and easy to understand ! Thanks for the content and now I'm Subscriber to your channel. Keep it up man
Really great and easy understandable explanation of smuggling requests - thanks \o/
I had some difficulties to get my head around http request smuggling. But you delivered a great mnemonic. I will associate Pizza ristorante with request smuggling forever.
Great! Glad it helped!
Now I got it, great explanation!
That is awesome, thanks for taking the time. Kudos for the artistic talent as well ;) !
Surprisingly good explanation.
Glad you liked it
Amazing video! Thank you for making it!
Quick question, at 17:14, you set the Content-Length to 800. If the victim's request isn't that long, wouldn't that result in the smuggled request being timed-out?
Thanks again 🙏
Awesome explanation and demo
thank you aaron
When you show TE/CL, the second chunk is 23, not 0 - so far so good. But since 23 is one character longer than 0, the header Content-Length should be changed from 10 to 11.
Great video!
Thanks!
Nice explanation bro.
Can you please explain the vulnerability insecure java and php deserialization?
The request body where the robot.txt is found can I still modify the supposed request to smuggle from there immediately rather than smuggling the robot.txt????
Hey , probably best explanation on request smuggling, Thanks!
However can you please clarify to me the use of "7f" in the request?
And the
1
Z
Q
Any help is appreciated
Thank's for your feedback!
When requests are sent with "Transfer-Encoding: chunked", we need to specify how many bytes we are sent like...
4 (--> 4 bytes are following)
id=1 (--> this is our payload and has 4 bytes)
0 (--> zero bytes follow. This is the end of our request)
In your second example, we defined an INVALID request to force a server into a timeout.
1 (--> 1 byte is following)
Z (--> our payload. Could be anything else like A, B, C, D, 1, 2, 3, 4, etc)
Q (--> here we would expect the next chunk length. So the request is INVALID, at least for chunked requests; this could be any other letter like A, B, C, D, etc)
The chunk lengths are defined as hexadecimal numbers. 7f in your first example is 127 in decimal (see: coolconversion.com/math/binary-octal-hexa-decimal/_hex__7F_to_decimal_), this means 127 bytes follow. The payload then actually has a length of 127 bytes and the 0 in the next line means: chunked payload ends here.
Thank you so much for the response!
Can we reject inserting the /r/n after some headers simply by escaping 1 line ?
@@mizo7627 I'm not sure I understand what you mean.
But you will probably not be able to replace carriage return/newline because this is part of the http standard.
You might want to give an example, what payload you are referring to and what you want to reach by replacing the characters.
I think it's more clear now,
Thanks for the response and hope to see more videos from you!
very nice explanations thanks a lot but I am a defender and what is the way to prevent this attack ? any idea , can you point me to that ?
Make sure your applications and web servers are all up to date.
If you implement your own webservers... wait... do not implement your own web servers.
bro how are you even writing?
GET /admin HTTP/1.1
foo: xGET / HTTP/1.1
host: innocent.com
cookie:....
bro plz tell me how the server reads the second line(ie,foo:xGET..)? or it just ignore the line??