0

I am currently trying to learn HTTP Request Smuggling vulnerability to further enhance my pen testing skills. I have watched a couple of videos on Youtube and read articles online regarding it but still have a couple of questions in mind:

  • What are the attack vectors of HTTP Req Smuggling (Where should I look)?
  • What is the main way to provide PoC to companies with high traffic? I know that HTTP Smuggling could possibly steal people's cookie, can this be used for the PoC or is this illegal?
  • Can this or other vulnerability be chained together? (e.g. self-xss & csrf)
  • I am also a bit confused regarding the CL & TE headers. From my observation, an app is vulnerable to request smuggling if both front-end and back-end interpret the CL & TE headers differently. I know how it works when its CL.TE attack, the front-end would include the body of the request based on the Content-Length and the backend would prioritize the Transfer-Encoding: Chunked header and therefore smuggling our 'additional' request body. But, how does it work on a TE.CL attack?
1

HTTP Request Smuggling is the attack used to steal cookies and other traffic-based credentials over a vulnerable configured server.

Attack vectors of HTTP Request Smuggling: (Use the Burp Suite for the following)

  • Parameters in the request. 2 parameters, Content-Length and Transfer-Encoding matter as the surface of this attack. If they both are present in the same request, it's likely that the request is dealing with the front-end and back-end server for parsing.

  • Also, the Transfer-Encoding parameter should be in a chunked state, this means that more than 1 servers are present on the other side. If another user is requesting the server at the same time, the request will randomly choose either front or back end server for processing on either of the parameters.

HTTP Request Smuggling is rated 7~8.9 in the criticality rate and can be considered a severe vulnerability. It should be included in a POC and is legal, unless the company does not provide the consent to you for testing their systems. POCs should either be provided on platforms like HackerOne or BugCrowd, or should be mailed to the security team with a private YouTube video describing it.

HTTP Request Smuggling can be chained with other tier-1 CDN-related attacks like cookie hijacking or sometimes a SSRF in case of a misconfigured server, token entropy or vulnerable headers.

For the CL;TE headers being, when you use an additional body in the request, the front-end and back-end server parse the body accordingly to the headers passed.

For example, if the following request is passed:

Content-Length: 13
Transfer-Encoding: chunked 

0
EXPLOITS

The front-end server is accepting the Content-Length header, thus it will parse out the EXPLOITS string and send the request to the back-end server. The back-end server will parse out 0 first and since it indicates 0 bytes, it will not process the request body beneath it as the parsing will stop. So, the EXPLOITS string will be unprocessed till a new request arrives and will process it including the new request and will give out the response to the new request.

The headers can be obfuscated in a number of ways, like

Transfer-Encoding: xchunked

Transfer-Encoding
: chunked 

Any obfuscation you can play with until you get the response in the repeater tab of Burp Suite resulting either a time delay or unexpected content. You can also send 2 quick succession queries to the server for confirming the vulnerability.

Hope this helps!

| improve this answer | |
New contributor
Ujas Dhami is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • Hi, thank you for your reply. For my first question, I was just wondering if there a specific endpoint where I should test this vulnerability or every endpoint is a potential for HTTP Req Smuggling? I listened to Albinowax presentation on DEFCON 27 (youtube.com/watch?v=w-eJM2Pc0KI), he mentioned that every endpoint should be tested. Is this true? And I added an additional question, would you mind taking a look at it? Thank you Ujas Dhami, much appreciated! – Emanuel Beni Sep 16 at 6:05
  • Yes, endpoints should be tested accordingly like the one about TE I mentioned above. You can try any other obfuscation technique you want with those endpoints and test for the vulnerable one. :) – Ujas Dhami 2 days ago
  • Noted! I know that the severity of this vulnerability is high - critical, but testing all endpoints seems to be a lot of work. Do you have a recommendation of tools to collect endpoints in order to feed into HTTP Smuggler tools (e.g. Smuggler by defparam)? – Emanuel Beni 2 days ago
  • I'm sorry, I don't have the knowledge of associated tools for this vulnerability. If talking of me, I manually test every endpoint for the reproduction so I could figure out the response of every obfuscated header passed. – Ujas Dhami 2 days ago
  • No problem! I have another speculation needed to be confirmed. Is it true that most HTTP Smuggling attack happened on POST request? Or others are likely to be vulnerable too? And do you have public write ups or reports that I could see? Maybe HackerOne or blogging account ? – Emanuel Beni 2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.