Re: From the linked article
Standards-compliant HTTP clients and servers will never read or send this header
Not quite correct. HTTP allows agents to define custom headers, so "Proxy" is allowed as such. To the bog-standard server, such as Apache or nginx out-of-the-box, it's as meaningful as "Vhjsrmwb" or "jasswe33d". And equally harmless.
The problem is that due to popular convention many web servers simply prefix HTTP_
That's not popular convention, it's the original CGI standard - which is inherited by all the CGI-imitators like PHP. A way to make headers available to applications that might be interested. All HTTP end-to-end or undefined headers except a few enumerated ones SHOULD be treated this way, but MAY be suppressed if they give rise to security issues.
The trouble arises where languages and libraries use HTTP_PROXY to mean something they shouldn't be taking from untrusted input. I haven't tested it, but I should imagine Perl used with taint-checking (as it always should be on the web) is safe. On the other hand, PHP is always vulnerable to everything, and more generally YMMV. Hence the web servers taking it on themselves to block an incoming Proxy header from propagating to the CGI environment.
The good news is that Apache and others are preventing the Proxy header specifically from being turned into an environmental variable, but we can't just automatically drop it because that is unexpected and somewhat rude.
Actually we can just drop it. If the backend application has a legitimate use for an HTTP_PROXY environment variable, it can be set in the server configuration, for example with Apache's SetEnv directive. But not from an untrusted source.
Biting the hand that feeds IT
