nginx+cgi解析php容易出現(xiàn)的漏洞的分析
發(fā)布時間：2012-10-25 14:42:19 作者：佚名 
我要評論
我要評論本文簡要的分析nginx+cgi解析php容易出現(xiàn)的漏洞
標題有點大，當我們仔細分析后，實際上一般都是配置問題。
如果有人想攻擊服務器時，都會掃描機器哪里有漏洞可以上傳惡意腳本文件，上傳腳本是第一步，
當惡意的php腳本被上傳到服務器時(其后綴可能是php，也可能偽裝如jpg等其它后綴)，
如果該腳本能被解析執(zhí)行，那想攻擊者就可以為所欲為了。
那從源頭上來避免這個問題可以從如下兩方面入手：
1.上傳前就應該判斷文件不能是php腳本文件，如果是不能允許其上傳(包括偽裝后綴的)。
2.上傳后就應該把上傳的附件文件單獨放在一個服務器，該機器只做靜態(tài)解析，就沒什么問題了。
第一條需要寫程序保證，沒什么說的，最簡單的判斷文件后綴，到file判斷文件類型，或者再復雜的，大家可以去網(wǎng)上找。
第二條解決起來可能礙于資源有限，也不好辦。那如果沒條件只有一臺機器的話，是不是只能人為刀俎，我為魚肉了呢。
其實也可以從配置上去避免，
禁止ngingx解析上傳目錄中的php文件。
location ~* ^/upload/.*\.(php|php5)($|/)
{
deny all;
}
避免偽裝其它后綴的腳本執(zhí)行
比如: 通過某種方法上傳了偽裝文件，upload下存在一個偽裝成圖片的php腳本a.jpg,
那么當使用http://www.nginx.cn/upload/a.jpg/b.php訪問時，
如果不做特殊設置傳給CGI執(zhí)行的SCRIPT_FILENAME就是$root/upload/a.jpg/b.php
當設置了cgi.fix_pathinfo = 1時，PHP就會以'/'為分割符從最后一個文件開始向前找存在的文件去執(zhí)行。
$root/upload/a.jpg/b.php
$root/upload/a.jpg
最終偽裝腳本將會被執(zhí)行。
解決方法：
1.關閉cgi.fix_pathinfo 設置成 cgi.fix_pathinfo = 0，但是會影響使用PATH_INFO進行rewrite的程序。
2.
location ~* .*\.php($|/)
{
if ($request_filename ~* (.*)\.php) {
set $php_url $1;
}
if (!-e $php_url.php) {
return 403;
}
}
如果有人想攻擊服務器時，都會掃描機器哪里有漏洞可以上傳惡意腳本文件，上傳腳本是第一步，
當惡意的php腳本被上傳到服務器時(其后綴可能是php，也可能偽裝如jpg等其它后綴)，
如果該腳本能被解析執(zhí)行，那想攻擊者就可以為所欲為了。
那從源頭上來避免這個問題可以從如下兩方面入手：
1.上傳前就應該判斷文件不能是php腳本文件，如果是不能允許其上傳(包括偽裝后綴的)。
2.上傳后就應該把上傳的附件文件單獨放在一個服務器，該機器只做靜態(tài)解析，就沒什么問題了。
第一條需要寫程序保證，沒什么說的，最簡單的判斷文件后綴，到file判斷文件類型，或者再復雜的，大家可以去網(wǎng)上找。
第二條解決起來可能礙于資源有限，也不好辦。那如果沒條件只有一臺機器的話，是不是只能人為刀俎，我為魚肉了呢。
其實也可以從配置上去避免，
禁止ngingx解析上傳目錄中的php文件。
location ~* ^/upload/.*\.(php|php5)($|/)
{
deny all;
}
避免偽裝其它后綴的腳本執(zhí)行
比如: 通過某種方法上傳了偽裝文件，upload下存在一個偽裝成圖片的php腳本a.jpg,
那么當使用http://www.nginx.cn/upload/a.jpg/b.php訪問時，
如果不做特殊設置傳給CGI執(zhí)行的SCRIPT_FILENAME就是$root/upload/a.jpg/b.php
當設置了cgi.fix_pathinfo = 1時，PHP就會以'/'為分割符從最后一個文件開始向前找存在的文件去執(zhí)行。
$root/upload/a.jpg/b.php
$root/upload/a.jpg
最終偽裝腳本將會被執(zhí)行。
解決方法：
1.關閉cgi.fix_pathinfo 設置成 cgi.fix_pathinfo = 0，但是會影響使用PATH_INFO進行rewrite的程序。
2.
復制代碼
代碼如下:location ~* .*\.php($|/)
{
if ($request_filename ~* (.*)\.php) {
set $php_url $1;
}
if (!-e $php_url.php) {
return 403;
}
}
相關文章
DedeCMS全版本通殺SQL注入漏洞利用代碼及工具2014年2月28日
近日，網(wǎng)友在dedecms中發(fā)現(xiàn)了全版本通殺的SQL注入漏洞，目前官方最新版已修復該漏洞,大家早點去官方下載補丁2014年2月28日2014-02-28路由器、交換機及防火墻漏洞的發(fā)現(xiàn)與防范方法
在本文中，我們將探討為什么這些設備容易受到攻擊，現(xiàn)在有多少惡意網(wǎng)絡攻擊是瞄準路由器、交換機和防火墻的以及企業(yè)應該采取什么措施來保護其網(wǎng)絡2013-12-11- 最近看到網(wǎng)上曝出的dedecms最新版本的一個注入漏洞利用，漏洞PoC和分析文章也已在網(wǎng)上公開.但是在我實際測試過程當中，發(fā)現(xiàn)無法復現(xiàn)2013-06-11
- 我們來分析一下163郵箱記事本存儲型Xss漏洞分析與補救措施2012-10-23
- 偶爾在網(wǎng)上看到這些，拿來和大家一塊看看，也好讓各個站長懂得保護自己的網(wǎng)站2012-10-16
微軟發(fā)布Fix it工具修復IE7/8/9漏洞 ie用戶請盡快修復(0day漏洞)
日前有安全機構(gòu)曝光了IE瀏覽器的一個0day漏洞，利用這個0day漏洞（CVE-2012-4681）攻擊者可以繞過Windows的ASLR（地址空間布局隨機化）防護機制，訪問用戶曾訪問過的計算機2012-09-20網(wǎng)站的九大敵人有哪些 千萬別給Web應用漏洞可趁之機
過去，網(wǎng)站的內(nèi)容大多是靜態(tài)的。隨著HTML5的流行，Web應用進入一個嶄新階段，內(nèi)容的動態(tài)化和實時共享讓阻攔不良內(nèi)容或惡意軟件變得更加復雜，公司和個人的重要信息也被暴于2012-08-23WEBSHELL箱子系統(tǒng)V1.0收信箱子代碼漏洞分析及解決方法
來分析一下WEBSHELL箱子系統(tǒng)的漏洞2012-08-17- 過去，網(wǎng)站的內(nèi)容大多是靜態(tài)的。隨著HTML5的流行，Web應用進入一個嶄新階段，內(nèi)容的動態(tài)化和實時共享讓阻攔不良內(nèi)容或惡意軟件變得更加復雜，公司和個人的重要信息也被暴于2012-08-09
小米MIUI系統(tǒng)漏洞致大量系統(tǒng)、軟件和用戶數(shù)據(jù)泄露及修復方法
MIUI的刷機量很大.出現(xiàn)下面這個漏洞要及時補啊2012-07-30