Hi! Thanks a lot for the wonderful explanation. Looks like you have had some personal experience around this. I came to know of this only after hearing about the AWS API vulnerability where cache was poisoned. Thanks again for the wonderful explanation. Again just to be more specific, this is only for HTTP 1.1. You have covered everyhing that we needed to know.
Burp issued a request, and got a response. Burp then issued the same request, but with a shorter Content-Length, and got a timeout. This suggests that the front-end system is using the Content-Length header, and the backend is using the Transfer-Encoding: chunked header. You should be able to manually verify this using the Repeater, provided you uncheck the 'Update Content-Length' setting on the top menu. As such, it may be vulnerable to HTTP Desync attacks, aka Request Smuggling. To attempt an actual Desync attack, right click on the attached request and choose 'Desync attack'. Please note that this is not risk-free - other genuine visitors to the site may be affected. Any idea about this?
This pattern of having a front end and back end server is becoming more prevalent in software development today. The reason for this is because of microservices in the cloud. You usually have an application running a language specific server such as NodeJS or Flask on the back end, and then a reverse proxy on the front end that forwards requests to one or more back end services. This helps serve static files faster since the front end server is often a fast application like Nginx and it can send the files without talking to the slower application server. It also allows for more scaling since you can have one reverse proxy at your IP communicating with lots of application servers to handle requests quickly. Because of this development pattern, one of the mitigation strategies that this video mentioned, making sure that the front end and back end servers are the same, is not feasible. Instead, to make your assessments more useful, suggest that they solve this vulnerability by ensuring the front end and back end process the headers in the same way.
Often times deveopers uses the third party products or frameworks and they do not have a control over how to configure it so it processes the headers same way.
The Request smuggling occurs when there is a mis-match on the client - server interpretation of the request. I have covered several cases in the video especially when it happens.
Hi! Thanks a lot for the wonderful explanation. Looks like you have had some personal experience around this. I came to know of this only after hearing about the AWS API vulnerability where cache was poisoned. Thanks again for the wonderful explanation. Again just to be more specific, this is only for HTTP 1.1. You have covered everyhing that we needed to know.
I always like to share my personal experience here as I think those are more valuable than just the bookish knowledge.
Wow! Really helpful! Thank you!👍👍
This was a great video!
clear information , a big thanks to you bro , you explained HTTP REQUEST SMUGGLING very well
thank you
Burp issued a request, and got a response. Burp then issued the same request, but with a shorter Content-Length, and got a timeout. This suggests that the front-end system is using the Content-Length header, and the backend is using the Transfer-Encoding: chunked header. You should be able to manually verify this using the Repeater, provided you uncheck the 'Update Content-Length' setting on the top menu. As such, it may be vulnerable to HTTP Desync attacks, aka Request Smuggling. To attempt an actual Desync attack, right click on the attached request and choose 'Desync attack'. Please note that this is not risk-free - other genuine visitors to the site may be affected.
Any idea about this?
Very well explained.
This pattern of having a front end and back end server is becoming more prevalent in software development today. The reason for this is because of microservices in the cloud. You usually have an application running a language specific server such as NodeJS or Flask on the back end, and then a reverse proxy on the front end that forwards requests to one or more back end services. This helps serve static files faster since the front end server is often a fast application like Nginx and it can send the files without talking to the slower application server. It also allows for more scaling since you can have one reverse proxy at your IP communicating with lots of application servers to handle requests quickly.
Because of this development pattern, one of the mitigation strategies that this video mentioned, making sure that the front end and back end servers are the same, is not feasible. Instead, to make your assessments more useful, suggest that they solve this vulnerability by ensuring the front end and back end process the headers in the same way.
Often times deveopers uses the third party products or frameworks and they do not have a control over how to configure it so it processes the headers same way.
Thanks for this video. Helpful content.
Check out the latest videos, those are more advance.
Thanks for the explanation
great video sir...
Hello, what would be the default protocol if there was no chunk-encoding or content-length that was set by the developer?
Hi, thank you for the great video! Could you please share with the source where you learned all this, maybe books or articles?
It is all online and my personal experience
Thank you for your explained
i have a question :
is the ( HTTP Request smuggling) just exist when the back-end have tow server and more ???
The Request smuggling occurs when there is a mis-match on the client - server interpretation of the request. I have covered several cases in the video especially when it happens.
What is the impact of this attack??
It really depends on the website/application or data it holds but mostly it is high.
Awesome
Thank You. xD
damn bruh indians are smart af
Thank you sir for the feedback
plzz expalie in hindi
no stfu