To work around this issue, do not use CGI on a server that is running IIS. CGI is a largely obsolete interface that is replaced by newer and more performance-related interfaces. Specifically, PHP, Python and Go should be hosted through FastCGI on IIS. FastCGI does not use environment variables for client request headers and does not have this issue. However for PHP, some applications may use PHPs
getenv() function to retrieve environment variables. Even when PHP is not hosted inside a CGI process, it replicates the CGI behavior by injecting request header values into the set of data available to its
getenv() function. If you use a PHP application that retrieves HTTP_PROXY in this manner, the following mitigations of clearing the header value or rejecting requests with a PROXY header are effective.
If you do have to use CGI for some reason, either block requests that contain a request header named "Proxy" or clear the value of the header. This is because "Proxy" is not a standard request header name and browsers will generally not send it.
To block a request that contains a Proxy header (the preferred solution), run the following command line:
appcmd set config /section:requestfiltering /+requestlimits.headerLimits.[header='proxy',sizelimit='0']
Note The appcmd.exe is not typically in the path and can be found in the %systemroot%\system32\inetsrv directory
To clear the value of the header, you can use the following URL Rewrite rule:
<system.webServer>
<rewrite>
<rules>
<rule name="Erase HTTP_PROXY" patternSyntax="Wildcard">
<match url="*.*" />
<serverVariables>
<set name="HTTP_PROXY" value="" />
</serverVariables>
<action type="None" />
</rule>
</rules>
</rewrite>
</system.webServer>
Note The URL Rewrite is a downloadable add-in to IIS and is not included in a default IIS installation.