首先表达一下结论，所有HTTP_开头的环境变量在CGI下都是不可信的。攻击者可以通过这个漏洞伪造环境变量，监听篡改你的请求。然后在配合强大的社工能力，让你损失巨大。虽然我并不是程序员，代码也是半吊子水平，但是深知网站被黑的损失。
我曾经接手过一个被黑过的网站，不管怎么操作，投诉网页快照，要求百度更新网站的快照；投诉页面，说明情况要求删除收录；提交死链等等，最后虽然处理完了，删除了被黑的页面，但是……
我却发现，网站被放进了沙盒，搜索引擎的蜘蛛一直在来，内容一直在更新，但是就是不放收录，也不给排名。
我都快疯了，放出沙盒看起来简直遥遥无期。
在我接收网站3个月后，终于看到了第一次收录的增长。这才勉强算是出了沙盒期，虽然这个网站本身的收录排名都算是太好，损失并不是很大，但是这次的HTTPOXY漏洞，影响确实非常的巨大，设想一个优化做的非常好的企业网站，3个多月的损失，甚至可能更长时间的损失，那对于企业网站推广的成果几乎是一个接近毁灭的打击。
非常有可能，所有的企业网站推广的工作，都要重来。
“兵者，国之大事，死生之地，存亡之道，不可不察也。”
首先，看下介绍漏洞的原文，
点击这里查看（https://httpoxy.org/），友情提醒，英语渣如艺绚小编这样的，嗯，还是不要太上心了，反正看的非常困难。
还是去鸟哥的博客（
http://www.laruence.com/2016/07/19/3101.html），看看他从PHP的角度来解释这个漏洞吧。
就是编程的时候，习惯性的命名HTTP_PROXY来作为环境变量的请求代理。但是在CGI(RFC 3875)的模式下，会把请求中的标头 (header)加上HTTP_前缀，注册为环境变量。所以如果攻击者在标头发送一个PROXY：xxx，PHP就会把它注册为HTTP_PROXY环境变量。
于是，恐怖的事情来了，getenv(“HTTP_PROXY”)就变成可被控制的了。所有类似的HTTP_开头的环境变量在CGI环境下，因为这个漏洞都将变得不可信。
只要你的服务会对外请求资源，并且服务跑在了CGI模式下(cgi, php-fpm)，都是有可能中招被攻击的。
最后鸟哥给出了PHP的解决办法：
以Nginx为例, 在配置中加入:
fastcgi_param HTTP_PROXY “”;
同时，除非是cli模式，记得要在代码中加入对sapi的判断：
If (php_sapi_name() == ‘sli’ && getenv(‘HTTP_PROXY’))
{
//只有cli模式下，HTTP_PROXY环境变量才是可控的，否则永远不要相信HTTP_PROXY环境变量
}
>