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
      <Proxy>
             DENY url.scheme=http url.port=!80

Restrict HTTPS requests going to non-standard https port
      <Proxy>
             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
       <Proxy>
             DENY proxy.address=!internal_subnets url.address=internal_subnets

define subnet internal_subnets
    10.0.0.0/8
    192.168.0.0/16
end subnet

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.