Software Engineering Institute

HTTP Host Headers are defined in RFC 2616 and are often used to by web servers to allow multiple websites to share a single IP address.

From RFC 2616:
A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL). For example, a request on the origin server for <http://www.w3.org/pub/WWW/> would properly include:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.

Transparent proxy servers intercept and redirect network connections without user interaction or browser configuration. Some transparent intercepting proxy implementations make connection decisions based on the HTTP host-header value. Browser plugins (Flash, Java, etc) may enforce access controls on active content by limiting communication to the site or domain that the content originated from. An attacker may be able to forge HTTP host-header (or other HTTP headers) via active content. A proxy server running in intercepting ("transparent") mode that makes connection decisions based on HTTP header values instead of source and destination IP addresses is vulnerable due the ability of a remote attacker to forge these values.

To successfully exploit this issue, an attacker would need to either convince a user to visit a web page with malicious active content or be able to load the active content in an otherwise trusted site. Note that this vulnerability only affects proxy servers that run in transparent mode and browser same origin policies prevent attackers from re-using authentication credentials (cookies, etc) to obtain further access. This issue does not apply to proxy servers running in reverse mode.

More information about this issue can be found in the Socket Capable Browser Plugins Result In Transparent Proxy Abusepaper.

An attacker may be able to make full connections to any website or resource that the proxy can connect to. These sites may include internal resources such as intranet sites that would not usually be exposed to the Internet.

Update
When possible, administrators are recommended to obtain updated software. See the systems affected section of this document for a partial list of affected vendors. In network architectures using NAT, fixing this issue may not be feasible. Administrators are encouraged to review the below workarounds.

Administrators can determine if their proxy server is vulnerable by reading the "Reproduction Instructions" section of the Socket Capable Browser Plugins Result In Transparent Proxy Abusepaper.

Workarounds for Administrators

It is possible to limit the impact of this vulnerability by restricting access in several ways. None of the below workarounds solve the issue, but they will significantly reduce the impact.

• Because an attacker can not access HTTP cookies, internal services that use an authentication scheme (such as a username/password) are not likely to be affected.
• Network designs that have limited connectivity between the proxy and internal services will prevent an attacker from obtaining direct access to these services via the proxy. Administrators should consider using access control lists or firewall rules to prevent direct connections between internal servers and proxy servers.
• Administrators should limit the CONNECT method to only the minimum required port range (usually 443/tcp).
• Limiting the range of ports a proxy server can communicate on will limit what resources an attacker can target. When possible, router or switch access control lists should be configured to prevent HTTP proxy servers using ports or protocols that they should not normally need access to. HTTP proxy servers do not usually need to communicate with well known ports other than 80/tcp and 443/tcp.

• To exploit this issue an attacker needs to execute active content (Java, Flash, Silverlight, etc) in the context of a web browser. Mozilla Firefox users should consider using the NoScript plugin to whitelist sites that can execute dynamic content. See the Securing Your Web Browser document for more information about secure browser configurations.

• In default configurations the proxy server should only be able to connect to a limited number of well known ports.
• The CONNECT method should only be allowed for traffic that uses destination port 443/tcp, unless the proxy is designed to act as a TCP tunnel on all ports.