Vulnerability Note VU#435052

Intercepting proxy servers may incorrectly rely on HTTP headers to make connections

Original Release date: 23 Feb 2009 | Last revised: 28 Sep 2009


Proxy servers running in interception mode ("transparent" proxies) that make connection decisions based on HTTP header values may be used by an attacker to relay connections.


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 <> would properly include:

GET /pub/WWW/ HTTP/1.1

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 Abuse paper.


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.


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 Abuse paper.

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.

Workarounds for users
    • 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.
Workarounds for proxy server vendors

Although these workarounds will not address the underlying issue, vendors who distribute HTTP proxy servers are encouraged to implement them to mitigate future vulnerabilities.
    • 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.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Apple Computer, Inc.Affected09 Dec 200811 Sep 2009
AstaroAffected-30 Apr 2009
Blue Coat SystemsAffected02 Jan 200904 Mar 2009
Internet Initiative JapanAffected-13 Apr 2009
QBIK New Zealand LimitedAffected15 Jan 200921 Jan 2009
SmoothWallAffected09 Dec 200820 Feb 2009
SquidAffected02 Jan 200923 Feb 2009
ZiproxyAffected13 Jan 200907 Aug 2009
Borderware TechnologiesNot Affected09 Dec 200803 Feb 2009
Check Point Software TechnologiesNot Affected09 Dec 200820 Feb 2009
Cisco Systems, Inc.Not Affected09 Dec 200812 Mar 2009
Cray Inc.Not Affected09 Dec 200817 Dec 2008
Debian GNU/LinuxNot Affected09 Dec 200820 Feb 2009
Extreme NetworksNot Affected09 Dec 200824 Apr 2009
Force10 Networks, Inc.Not Affected09 Dec 200804 Feb 2009
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A



Thanks to Robert Auger from the PayPal Information Risk Management team for reporting this issue as well as providing technical information.

This document was written by Ryan Giobbi.

Other Information

  • CVE IDs: Unknown
  • Date Public: 23 Feb 2009
  • Date First Published: 23 Feb 2009
  • Date Last Updated: 28 Sep 2009
  • Severity Metric: 3.54
  • Document Revision: 139


If you have feedback, comments, or additional information about this vulnerability, please send us email.