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

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