With the advent of HTTP-aware firewalls, IPSs, a lot of developers relax a little bit on strengthening the security of an application. Application firewalls are able to lock out most of the automated attacks on websites. However a new attack vector has been discovered which can bypass application firewalls too. HTTP request smuggling allows an attacker to send malicious requests across proxies and firewalls to the web server. Let's have a short description of the attack techinique.
HTTP Request Smuggling (HRS) attack is the result of a device failure to properly handle deformed inbound HTTP requests. HRS works by taking benefit of the discrepancies in HTTP request parsing when one or more HTTP devices are in the data flow between the user and the web server. HTTP Request smuggling leads to various attacks like web cache poisoning, session hijacking, cross-site scripting etc.
How it works
When client sends HTTP request, it will go through various applications like Cache, proxy, firewall etc. before reaching to the web server. Attacker will modify the request in these intermediate points. Hence we call it as smuggling of request in-between the source and destination.
Attacker sends multiple specially-crafted HTTP requests which cause the two entities to see different sets of requests. This result into smuggle a request to one device without the other device being aware of it.
Let’s take a look at how a typical web cache poisoning can be carried out using HRS:
Figure 1. HTTP Request Smuggling
- The attacker targets the cache service used by the organization to reduce load on the internet bandwidth. This server can be a cache server on the LAN or other application server caching the static WebPages. The attacker sends three different HTTP request as shown below
Request 1: POST request for http://www.netbanking.com
Request 2: GET request for http://www.netbanking.com/FD.html
Request 3: GET request for http://www.netbanking.com/FD-Rates.html
- Due to malformed request cache server assumes request 1 and 3 as valid request and forwards the entire request to the webserver.
- Webserver which strictly follow then HTTP parsing rule responds with the http://www.netbanking.com/FD.html HTML page. This is happened because webserver consider request 1 and 2 as valid one.
- Cache server stores this response against the request 3
- When normal users request for page http://www.netbanking.com/FD-Rates.html, cache server responds with the page http://www.netbanking.com/FD.html.Hence attacker will succeeds in cache poisoning.
Who is vulnerable?
Devices handling HTTP requests in between the client and server are vulnerable to HRS. Following devices on site or client side might be prone to HRS attacks:
- Cache server used to cache the static pages in order to limit bandwidth traffic. Cache servers are prone to cache poisoning using HRS.
- Proxy server used to connect the internal LAN to the internet. Request hijacking can be possible by using proxy server.
- Firewall used to protect web site or internal LAN from other networks. Firewalls are prone to Warm attack using HRS.
- Other devices such as SSL accelerator, IDS, Load balancer and internet browsers are also prone to HRS attacks.
How difficult is the attack?
HRS doesn’t need weakness in the client or web server rather it only require knowledge of HTTP protocol. Since HRS involves playing with HTTP request fields like content-length, body size etc. Further attacks like cross site scripting and cross site tracing can be carried out by injecting script into the HTTP request. This requires knowledge of scripting language. Hence for normal users it’s difficult to carry out HRS attack.
What are the threats involved?
Following threats are resulted using HRS:
- Financial loss result of web site deforming which can be carried out by cache poisoning the cache server.
- Steal user credential using cross site scripting or cross site tracing attacks (XST).This can be achieve by injecting script into smuggle HTTP request. Although many webserver now days disable the trace method but this attack is possible using TRACE method enable on the proxy servers.
- Warm attack like Nimda by attacking web filter firewalls.
What are the solutions available?
- Install web application firewall which protects against the HRS attacks. Few firewalls are still vulnerable to the HRS. Check with the firewall vendor if there product protects against HRS.
- Deploy web server which follows strict HTTP parsing procedure. Some Webservers like Apache follows strict HTTP parsing and hence less vulnerable to HRS attacks.
- Allow only SSL communication from client to server. This still leaves the site vulnerable to cache poisoning attack.
- Apply strong session management techniques. Terminate the session after each request.
- Disable TRACE method on the proxy server.
- Turn off TCP connection sharing on the intermediate devices. TCP connection sharing improves the performance but it allows attacker to smuggle HTTP request.
- Do not use NTLM authentication on the web server. NTLM authentication used with the proxy server shares TCP connections for several clients.
- Turn on non-cache for all pages. For more details refer to http://www.web-caching.com/
- "HTTP Request Smuggling", Chaim Linhart, Amit Klein, Ronen Heled and Steve Orrin, June 2005
- HTTP Message Splitting, Smuggling and Other Animals, OWASP AppSec EU 2006 Presentation by Amit Klein.