nginx+cgi解析php容易出現(xiàn)的漏洞的分析
發(fā)布時間:2012-10-25 14:42:19 作者:佚名
我要評論

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