Location HTTP header injection vulnerability

On February 14th, an advisory posted on BugTraq (bugtraq, InfoHacking) described two ways to inject data into HTTP responses using a crafted request.

• The "Error response arbitrary injection" method is not applicable to Zeus Web Server.

• The "Location HTTP header injection" affects Zeus Web Server. A number of other web servers, including Apache and IIS, can also be provoked in this way.

This article discusses the advisory as it pertains to Zeus Web Server, and assesses how it may be exploited to provoke undesired behaviour.

Overview

An HTTP request generally contains a URL and a Host header:

GET /docs HTTP/1.1
Host: www.site.com

Many requests ordinarily return "redirect" responses, instructing the client to request a different resource:

HTTP/1.1 301 Moved Permanently
Location: http://www.site.com/docs/

The location response value is constructed from the host header value and the URL.

The advisory describes how many web servers can be provoked to issue an incorrect redirect by supplying a carefully crafted, invalid host header. For example, using the host header www.site.com:8080/fake in the above request may cause the web server to return a redirect to http://www.site.com:8080/fake/docs/. This will cause the client to request the wrong URL.

No standard web client would accidentally or deliberately cause this behaviour. This behaviour can only be caused by a deliberately mal-formed HTTP request.

Exploiting this Location redirect behaviour

The advisory surmises that this behaviour could be exploited by poisoning a web cache with the invalid response, so that legitimate users received the invalid redirect when accessing the web site. The advisory is broadly incorrect in this respect; web caches will cache responses based on the request URL and Host header (as well as other criteria), so will only issue the invalid redirect to requests that contain the invalid host header.

One exception occurs when the web cache is deliberately configured to ignore the host header when caching responses. This is a suggested configuration when using Squid as an HTTP accelerator directly in front of a web server that only hosts one web site (domain). It cannot be used when using Squid to accelerate multiple domains.

If you are fronting a web server with a reverse proxy cache that has been configured to ignore host headers, it may be possible to poison the cache and mount an effective Denial of Service attack.

Workaround

If you are concerned about this behaviour, you can configure Zeus Web Server to remove path and port components from host headers in a request. The following Request Rewriting rule can be applied to your virtual servers:

# Remove any trailing :port or /URL from Host header
match IN:Host into $ with ([^:/]*)
if matched then
  set IN:Host = $1
endif

Other Observations

Preserving the port in the host header is a necessary consequence of the HTTP protocol, and HTTP allows for host headers that include port numbers. This caters for the possibility that the public port is different to the actual internal port (for example, when running through a proxy on the same server).

Zeus Technology works closely with customers, evaluators, security professionals and other researchers to ensure its products are secure and free from defects. Any security-related comments received at security@zeus.com, or through any other means, are treated as being of the utmost importance. Zeus respectfully requests that security issues are notified directly to Zeus before being publicly disclosed.