Initial Publication Date: Advisory Status: Advisory Severity: Legacy ID
2 Mar 2009 Closed Medium
This impacts ProxySG in transparent deployments intercepting HTTP/HTTPS traffic.
An attacker may compromise a browser plug-in (Flash, Java Applet etc) to insert an HTTP Host header in an HTTP/HTTPS request. By default, ProxySG relies on the HTTP Host header to determine which upstream host to connect to and so will end up connecting to the host indicated in the forged Host header. This might allow the attacker to access any servers that proxy can access to including servers that were not exposed to external users, rather than being limited to the server the plug-in or applet was downloaded from.
This is not a deficiency in ProxySG. Its choice to always resolve the hostname in Host headers by default is, in fact, a security feature to prevent clients from connecting to unauthorized hosts. However, in transparent deployments, it does allow the attacker to attempt this attack. The ProxySG provides the following features that enable administrators to either limit the impact or completely avoid this vulnerability:
Use ProxySG policy controls to restrict proxy access to servers. Following are some policy examples that are relevant to this attack.
Restrict HTTP requests going to non-standard HTTP port
DENY url.scheme=http url.port=!80
Restrict HTTPS requests going to non-standard https port
DENY url.scheme=https url.port=!443
Deny HTTP requests going to an external address where the Host header contains an address in an internal subnet
DENY proxy.address=!internal_subnets url.address=internal_subnets
define subnet internal_subnets
Note: Please make sure you replace the subnets above my your own internal subnet(s)
Enable the trust-destination-ip setting (only available on SGOS 5.2 onwards). This can be done through configuration or policy. Enabling this setting will cause the ProxySG to trust the destination IP over the host specified in the Host header, thus completely ignoring the forged Host header that the attacker inserted.
Caveat: If your deployment is using a content-filtering solution to restrict user access, enabling trust-destination-ip may cause an attacker to bypass this restriction – if an attacker sends an HTTP request with destination IP of a blocked site and a Host header containing a hostname of a non-blocked site, the ProxySG will end up allowing such a request since content filtering uses the Host header. Enabling trust-destination-ip is not recommended for this type of deployment.