Do not use HTTP_PROXY environment variable

[lucaswerkmeister]

In some CGI servers, notably older versions of Apache (prior to the HTTPoxy response), an attacker can set the HTTP_PROXY environment variable by sending a Proxy: request header. Applications and libraries should therefore not use the contents of this variable as an HTTP proxy; compare curl, just a few lines after the code snippet linked under “external resources” (link):

    /*
     * We don't try the uppercase version of HTTP_PROXY because of
     * security reasons:
     *
     * When curl is used in a webserver application
     * environment (cgi or php), this environment variable can
     * be controlled by the web server user by setting the
     * http header 'Proxy:' to some value.
     *
     * This can cause 'internal' http/ftp requests to be
     * arbitrarily redirected by any external attacker.
     */
    if(!prox && !Curl_raw_equal("http_proxy", proxy_env)) {
      /* There was no lowercase variable, try the uppercase version: */
      Curl_strntoupper(proxy_env, proxy_env, sizeof(proxy_env));
      prox=curl_getenv(proxy_env);
    }

But proxy-from-env is currently happy to read a proxy from the HTTP_PROXY environment variable, thus making its users potentially proxy traffic through an attacker’s server. It should only use http_proxy, lowercase.

[Rob--W]

Interesting find! Is the issue still relevant today?

That check in curl's source code is over two decades old (curl/curl@18f044f). The publication that you referenced is from 6 years ago.

These days, the HTTP_PROXY environment variable appears to still be prevalent, and dropping support for that may be confusing and surprising to users/devs. E.g. mentioned in:

• http: support environment-defined proxy nodejs/node#8381
• https://github.com/request/request#controlling-proxy-behaviour-using-environment-variables
• https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/#state-of-the-variables-today

[silverwind]

Uppercase variables can not be removed, it's very widespread in use.

This sounds like a bug in Apache to me. It should not blindly set significant environment variables based on untrusted HTTP headers.