Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

HTTP smuggling

[ | Last updated: Mar 03, 2022 09:44AM UTC

In this tutorial there is a Note that says: The "attack" request and the "normal" request should be sent to the server using different network connections. Sending both requests through the same connection won't prove that the vulnerability exists. So what does it mean? For example i want to send this request to Confirming TE.CL vulnerabilities: POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 4 Transfer-Encoding: chunked 7c GET /404 HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 144 x= 0 that Note says i should send normal and attack with different networks. I was completely confused about what that meant!

Liam, PortSwigger Agent | Last updated: Mar 03, 2022 02:44PM UTC

Thanks for your message. Could you provide a link to the tutorial, please?

[ | Last updated: Mar 03, 2022 03:19PM UTC

https://portswigger.net/web-security/request-smuggling/finding

[ | Last updated: Mar 03, 2022 03:19PM UTC

https://portswigger.net/web-security/request-smuggling/finding

Liam, PortSwigger Agent | Last updated: Mar 03, 2022 04:02PM UTC

Thanks for clarifying.

Today's web applications frequently employ chains of HTTP servers between users and the ultimate application logic. Users send requests to a front-end server (sometimes called a load balancer or reverse proxy) and this server forwards requests to one or more back-end servers. This type of architecture is increasingly common, and in some cases unavoidable, in modern cloud-based applications.

When the front-end server forwards HTTP requests to a back-end server, it typically sends several requests over the same back-end network connection, because this is much more efficient and performant.

In a request smuggling attack, the attacker (using a different network connection) causes part of their front-end request to be interpreted by the back-end server as the start of the next request.


Please let us know if you need any further assistance.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.