httpoxy漏洞是一個剛暴露出來的漏洞，它針對 PHP、Go、Python 等語言的 CGI 應用的漏洞。它將apache等元件中用於代理HTTP訪問的欄位名變換為“HTTP_PROXY”，再傳遞給對應的CGI來執行。如果CGI或者指令碼中對外請求的元件依賴於“HTTP_PROXY”這個環境變數，那就中招了，會導致遠端攻擊。
HTTP_Proxy是什麼
www對於每一個上網的人都再熟悉不過了，www連線請求就是採用的代理。我們在瀏覽網頁，下載資料（也可採用ftp協議）時就是用http代理。它通常繫結在代理伺服器的80、3128、8080等埠上。
httpoxy漏洞是一個伺服器端 web 應用漏洞，如果你沒有在伺服器端部署這些程式碼，則不用擔心。但如果你正在執行著 PHP 或 CGI 程式，你應該馬上封擋 Proxy 頭部!馬上! 具體做法參見下面。
如果我的 Web 應用存在這種漏洞會怎麼樣?
當一個利用了此漏洞的 HTTP 客戶端發起請求時，它通過你的 Web 應用去代理請求別的 URL，直接讓你的伺服器開啟指定的遠端地址及埠，浪費伺服器的資源，替攻擊者訪問指定的資源
httpoxy漏洞非常容易利用。希望安全人員儘快掃描該漏洞並快速修復。
哪些系統受到影響?
以下情況會存在安全漏洞：
程式碼執行在 CGI 上下文中，這樣 HTTP_PROXY 就會變成一個真實的或模擬的環境變數 一個信任 HTTP_PROXY的 HTTP 客戶端，並且支援代理功能 該客戶端會在請求內部發起一個 HTTP(或 HTTPS)請求
下列情形是已經發現存在該缺陷的環境：
語言環境HTTP 客戶端PHP php-fpm
mod_php Guzzle 4+
Artax Python wsgiref.handlers.CGIHandler
twisted.web.twcgi.CGIScript requests Go net/http/cgi net/http
肯定還有很多我們沒有確定是否存在缺陷的語言和環境。
PHP
是否存在缺陷依賴於你的應用程式碼和 PHP 庫，但是影響面看起來似乎非常廣泛 只要在處理使用者請求的過程中使用了一個帶有該缺陷的庫，就可能被利用 如果你使用了有該缺陷的庫，該缺陷會影響任意 PHP 版本 甚至會影響到替代的 PHP 執行環境，比如部署在 FastCGI 模式下的 HHVM 確認影響 Guzzle、Artax 等庫，可能還有很多很多的庫也受影響 Guzzle 4.0.0rc2 及其以後版本受影響，Guzzle 3 及更低版本不受影響 其它的例子還有 Composer 的 StreamContextBuilder 工具類
舉個例子說，如果你在 Drupal 中使用 Guzzle 6 模組發起外發請求(比如請求一個天氣 API)，該模組發起的請求就存在這個 httpoxy 缺陷。
Python
Python 程式碼只有部署在 CGI 模式下才存在缺陷，一般來說，存在缺陷的程式碼會使用類似wsgiref.handlers.CGIHandler 的 CGI 控制器 正常方式部署的 Python web 應用不受影響(大多數人使用 WSGI 或 FastCGI，這兩個不受影響)，所以受到影響的 Python 應用要比 PHP 少得多 wsgi 不受影響，因為 os.environ 不會受到 CGI 資料汙染 存在缺陷的 requests 庫必須信任和使用 os.environ[`HTTP_PROXY`]，並且不做內容檢查Go Go 程式碼必須部署在 CGI 下才受影響。一般來說受到影響的程式碼會使用 net/http/cgi 包 像 Python 一樣，這並不是部署 Go 為一個 Web 應用的通常方式。所以受到影響的情形很少 相較而言，Go 的 net/http/fcgi 包並不設定實際的環境變數，所以不受影響 存在缺陷的 net/http 版本需要在外發請求中信任並使用 HTTP_PROXY ，並不做內容檢查馬上修復
httpoxy漏洞修復方式
最好的修復方式是在他們攻擊你的應用之前儘早封擋 Proxy 請求頭部。這很簡單，也很安全。
說它安全是因為 IETF 沒有定義 Proxy 請求頭部，也沒有列在 IANA 的訊息頭部註冊中。這表明對該頭部的使用是非標準的，甚至也不會臨時用到 符合標準的 HTTP 客戶端和伺服器絕不應該讀取和傳送這個頭部 你可以從請求中去掉這個頭部或者乾脆整個封擋使用它的請求 你可以在上游沒有釋出補丁時自己來解決這個問題 當 HTTP 請求進來時就檢查它，這樣可以一次性修復好許多存在缺陷的應用 在反向代理和應用防火牆之後的應用剔除 Proxy 請求頭部是安全的
如何封擋 Proxy 請求頭部依賴於你的配置。最容易的辦法是在你的 Web 應用防火牆上封擋該頭部，或者直接在 Apache 和 Nginx 上做也行。以下是一些如何做的指導：
Nginx/FastCGI
使用如下語句封擋傳遞給 PHP-FPM、PHP-PM 的請求頭，這個語句可以放在 fastcgi.conf 或 fastcgi_param 中(視你使用了哪個配置檔案)：
fastcgi_param HTTP_PROXY “”;
在 FastCGI 模式下，PHP 存在缺陷(但是大多數使用 Nginx FastCGI 的其它語言則不受影響)。
Apache
對於 Apache 受影響的具體程度，以及其它的 Apache 軟體專案，比如 Tomcat ，推薦參考 Apache 軟體基金會的官方公告。以下是一些主要資訊：
如果你在 Apache HTTP 伺服器中使用 mod_cgi來執行 Go 或 Python 寫的指令碼，那麼它們會受到影響(這裡 HTTP_PROXY 環境變數是“真實的”)。而 mod_php 由於用於 PHP 指令碼，也存在該缺陷。
如果你使用 mod_headers 模組，你可以通過下述配置在進一步處理請求前就 unset 掉 Proxy 請求頭部：
RequestHeader unset Proxy early
如果你使用 mod_security 模組，你可以使用一個 SecRule 規則來拒絕帶有 Proxy 請求頭部的請求。下面是一個例子，要確保 SecRuleEngine 開啟了。你可以根據自己的情況調整。
SecRule &REQUEST_HEADERS:Proxy “@gt 0” “id:1000005,log,deny,msg:`httpoxy denied`”
最後，如果你使用 Apache Traffic Server 的話，它本身不受影響。不過你可以用它來剔除掉 Proxy 請求頭部，以保護其後面的其它服務。具體可以參考 ASF 指導。
HAProxy
通過下述配置剔除該請求頭部：
http-request del-header Proxy
Varnish
通過下述語句取消該頭部，請將它放到已有的 vcl_recv 小節裡面：
sub vcl_recv {[…]unset req.http.proxy;[…]}
OpenBSD relayd
使用如下語句移除該頭部。把它放到已有的過濾器裡面：
http protocol httpfilter {match request header remove “Proxy”}
lighttpd (<= 1.4.40)
彈回包含 Proxy 頭部的請求。
建立一個 /path/to/deny-proxy.lua檔案，讓它對於 lighttpd 只讀，內容如下：
if (lighty.request[“Proxy”] == nil) then return 0 else return 403 end
修改 lighttpd.conf 以載入 mod_magnet 模組，並執行如上 lua 程式碼：
server.modules += ( “mod_magnet” )magnet.attract-raw-url-to = ( “/path/to/deny-proxy.lua” )
lighttpd2 (開發中)
從請求中剔除 Proxy 頭部。加入如下語句到 lighttpd.conf中：
req_header.remove “Proxy”;
使用者端的 PHP 修復沒有作用
使用者端的修復不能解決該缺陷，所以不必費勁：
使用 unset($_SERVER[`HTTP_PROXY`]) 並不會影響到 getenv() 返回的值，所以無用 使用 putenv(`HTTP_PROXY=`) 也沒效果(putenv 只能影響到來自實際環境變數的值，而不是來自請求頭部的)
httpoxy漏洞過往歷史
2001 年 3 月
Randal L. Schwartz 在 libwww-perl 發現該缺陷並修復。
2001 年 4 月
Cris Bailiff 在 curl 中發現該缺陷並修復。
2012 年 7 月
在Net::HTTP 的 HTTP_PROXY 實現中， Ruby 團隊的 Akira Tanaka 發現了該缺陷
2013 年 11 月
在 nginx 郵件列表中提到了該缺陷。發現者 Jonathan Matthews 對此不太有把握，不過事實證明他是對的。
2015 年 2 月
Stefan Fritsch 在 Apache httpd-dev 郵件列表中提到了它。
2016 年 7 月
Vend 安全團隊的 Scott Geary 發現了對該缺陷，並且它影響到了 PHP 等許多現代的程式語言和庫。
所以，這個缺陷已經潛伏了許多年，許多人都在不同方面發現了它的存在，但是沒有考慮到它對其它語言和庫的影響。安全研究人員為此專門建立了一個網站： https://httpoxy.org/ ，可以在此發現更多內容。