HTTP request smuggling: All that you Need to Know

What is HTTP request smuggling?

Let’s see the literal meaning of this phrase to comprehend what it is.

As we all know, HTTP is used by web-based sites and apps. The website/client and its server systematically exchange requests (HTTP-based) and communicate using it.

However, an inconsistent request acts as an opportunity for hackers. They use this weakness for various unethical purposes including HTTP request smuggling attacks. As per records, the oldest one, in this row, succeeded in the year 2005. In 2020, its multiple new variants were witnessed.

The Outcome(s)

In modern-day web solutions, the continual exchange of HTTP calls/requests is what makes communication successful. Such requests are coming and going continually, in this scenario.

To maintain the equilibrium, both frontend as well as backend servers must process requests according to HTTP related ruleset. Whenever there are any irregularities, a hacker can introduce a corrupted request/input because 2 servers process it separately. It is the beginning of the attack that has severely negative results, as a hacker can succeed in accessing the core information and taking its advantage.

‍

The Final Impact of Such Attacks

If getting into the hands of a skilled hacker, a smuggling threat is capable of carrying out damages beyond one’s understanding. It may help attacker in:

• Winning over the core-level security controls & entering into a system authorization
• Accessing the admin dashboard of a site
• Viewing/distorting sensitive user data information
• Creating a path for further attacks like XSS and SQL injection
• Hijacking of web user data and login credentials

‍

Methods

The very first requirement to succeed at attacking through HTTP is to combine the CL and TE headers. Using this trick, the hacker confuses front as well as backend server and pushes them to inconsistently in HTTP request handling. Here are the 3 top ways to make it happen:

CL.TE (Content-Length.Transfer-Encoding) Vulnerabilities

This loophole occurs is caused due to the frontend server forwardings/processing the CL while TE header is taken care of by the backend server. Here is a sample code to explain this.

POST / HTTP/1.2
Host: example-website-url.com
Content-Length: 20
Transfer-Encoding: chunked

 0 

Succeeded

Let us see how it works:

Frontend server sees the input for the CL header and learns that the length of stream to be processed will be 20 bytes.

The information is passed to the backend server, which reads the TE header to find out that ‘chunked’ processing needs to be done.

The 1st chunk (with length 0) is processed and terminated.

‘Succeeded’ bytes won’t be processed and left out by this server as it will consider it as the beginning of a new HTTP request. But, it’s not. This causes a variation in HTTP request handling. Hence, the attack is successful.

‍

TE.CL (Transfer-Encoding.Content-Length) Vulnerabilities 

‍

In this method, the front server will process TE header while the CL header process is in the functions list of the backend server. Have a look at a sample code created to conduct such a sort of attack.

HOST / HTTP/1.2
Host: example-website-url.com
Content-Length: 4
Transfer-Encoding: chunked 

11

COMPROMISED

0

Now, let’s understand how this method succeeds. When TE is processed by the front-end server, it handles the HTTP request body as per the chunked encoding.

Chunk 1 (of 11 bytes) is processed first and chunk 2 (of 0 bytes), thereafter.

Now, the backend server notices Content-Length header (4 bytes length) and skips to process COMPROMISED, considering it as another request.

‍

TE-TE Behavior (Transfer-Encoding) Vulnerabilities

Lastly, we have the TE-TE behavior method wherein only the TE header is sent to front and backend servers. This is also referred to as obfuscation of TE header as it’s overexploited and also one of the involved servers involved will be forced not to process the header somehow. 

See a few http request smuggling payloads below:

Transfer-Encoding: ychunked

Transfer-Encoding:  chunked

—————————————

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

—————————————

Transfer-Encoding : chunked

Transfer-Encoding

: chunked

From the above examples, it’s clear that the TE will only shift a bit from the actual HTTP specification which will make it look like a legitimate HTTP request. Hence, most of the server implementations will accept and process it as logical HTTP requests. 

The only thing that a hacker needs to carry out this type of attack is the ability to create multiple variations of the TE header. The higher the diversion, the better the success rate.

Improved HTTP request smuggling attacks

Replacing a regular response

Only possible when a cache server is present in middleware, this attack type involves performing cache corruption. The target here is invalid responses that are part of cache entries. It creates the base for a denial of service attack.

Bypassing Filters

It involves forwarding a corrupted request to the backend server directly while avoiding the security filters deployed.

Credentials Hijacking

It involves introducing a small query section to the query stream and waiting till the time a verified end-user query shows up. When it appears, the hacker accesses that verified user query and makes it a part of the initial small query section. As a verified query is linked with a malicious query, a proxy server or load balancer considers the corrupted query as legitimate and processes it.

‍

Prevention and Remediation

Trying early and workable cures upon detection of the problem are the only way to control the damage and safeguard network/server/client-side assets. Here are some of the most preferred techniques to use when remediation is on your mind:

• Always monitor HTTP requests

The very basic HTTP request smuggling remediation is to monitor the server and client-side HTTP requests. The better would be the monitoring, the early would be the detection, and the lower would be the damage. However, it’s important to understand that it’s not a 100% achievable task as load balancers that are crucial for backend server management are deployed at remote locations.

If you are following the common practice of using different platforms to manage the 2 servers to keep track of HTTP request processing, it is still ok. Just focus on how they interpret them and use the mix right.

• Inactive the performance optimization

Changing backend configuration isn’t always suggested and preferred. However, one must always ensure to disable the optimization performance that is related to the CL and TE headers. It’s obvious to experience a certain slowdown in the web ecosystem’s performance but it is a quick HTTP request smuggling fix.

• Reduce the use of resources like load balancers and proxy servers  

If not handled properly, these tools will help hackers to exploit you. So, unless it’s very crucial for your web ecosystem, don’t use these tools.

• Deploy a WAF

A good quality WAF is not less than a boon for the website as it filters the traffic and ensures that no malicious link or code is reaching your website.

• Don’t expose HTTP logs to unauthorized users

Make sure that the HTTP logs are secured and are only accessed by verified users. If possible, apply user authentication to access these.

‍

How can a Wallarm stop such an attack?

If you’ve read through the article, you must have understood that HTTP request smuggling is a matter of concern for every website owner. This is why Wallarm provides a highly extensive web security solution that has many ways to control this attack and prevent the associated risks/threats, such as: 

1. GoTestWAF is an inventive way to protect a website as it helps you find out the utility of installed WAF. This is an open-source tool developed with the use of ultra-modern detection technologies. It ensures that only workable WAFs are protecting your website and that further improves the security. It will also help you resolve the ‘how to test HTTP request smuggling’ mystery.
2. Its high-end and advanced Cloud WAF or Cloud Web Application Firewall tool ensures that traffic coming to your website is utterly secured. It features nearly zero false rates and promises to protect the website against OWASP Top 10 Threats. What makes this WAF unique amongst others is its unmatched detection technology that includes lib detection and bypass resistance.
3. API Security Platform of Wallarm is an ultra-modern way to safeguard the web API. As it’s compatible with all the leading APIs such as REST and SOAP, you can implement it without any worries. Its proactive security approach ensures that none of the API endpoints is left unprotected in any of the ecosystems. Starting from threat detection to early remedial, this platform can do tons of things in one go.

Try Wallarm today and keep your website safe from HTTP request smuggling OWASP threats. (You can take a free trial first.)