nginx下文件類型錯誤解析漏洞及處理方法

漏洞分析：nginx默認以cgi的方式支持php的運行，譬如在配置文件當中可以以

location ~ .php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}

的方式支持對php的解析，location對請求進行選擇的時候會使用URI環境變量進行選擇，其中傳遞到后端Fastcgi的關鍵變量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name決定，而通過分析可以看到$fastcgi_script_name是直接由URI環境變量控制的，這里就是產生問題的點。而為了較好的支持PATH_INFO的提取，在PHP的配置選項里存在cgi.fix_pathinfo選項，其目的是為了從SCRIPT_FILENAME里取出真正的腳本名。
那么假設存在一個，我們以如下的方式去訪問

http://www.80sec.com/80sec.jpg/80sec.php

將會得到一個URI

/80sec.jpg/80sec.php

經過location指令，該請求將會交給后端的fastcgi處理，nginx為其設置環境變量SCRIPT_FILENAME，內容為

/scripts/80sec.jpg/80sec.php

而在其他的webserver如lighttpd當中，我們發現其中的SCRIPT_FILENAME被正確的設置為

/scripts/80sec.jpg

所以不存在此問題。
后端的fastcgi在接受到該選項時，會根據fix_pathinfo配置決定是否對SCRIPT_FILENAME進行額外的處理，一般情況下如果不對fix_pathinfo進行設置將影響使用PATH_INFO進行路由選擇的應用，所以該選項一般配置開啟。Php通過該選項之后將查找其中真正的腳本文件名字，查找的方式也是查看文件是否存在，這個時候將分離出SCRIPT_FILENAME和PATH_INFO分別為

/scripts/80sec.jpg和80sec.php

最后，以/scripts/80sec.jpg作為此次請求需要執行的腳本，攻擊者就可以實現讓nginx以php來解析任何類型的文件了。
POC： 訪問一個nginx來支持php的站點，在一個任何資源的文件如robots.txt后面加上/80sec.php，這個時候你可以看到如下的區別：
訪問http://www.80sec.com/robots.txt

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

訪問訪問http://www.80sec.com/robots.txt/80sec.php

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的Content-Type的變化說明了后端負責解析的變化，該站點就可能存在漏洞。
漏洞廠商：http://www.nginx.org
解決方案：
我們已經嘗試聯系官方，但是此前你可以通過以下的方式來減少損失

關閉cgi.fix_pathinfo為0

或者

if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}
使用此方法時，將此段代碼放置在nginx/sites-enabled/ 下的各網站配置文件中，修改后重啟nginx。（注：開重寫的網站，查看跳轉地址后使用）

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈