nginx解析漏洞復(fù)現(xiàn)

一、漏洞描述

該漏洞與nginx、php版本無關(guān),屬于用戶配置不當(dāng)造成的解析漏洞

二、漏洞原理

1、 由于nginx.conf的如下配置導(dǎo)致nginx把以’.php’結(jié)尾的文件交給fastcgi處理,為此可以構(gòu)造http://ip/uploadfiles/test.png/.php (url結(jié)尾不一定是‘.php’,任何服務(wù)器端不存在的php文件均可,比如’a.php’),其中test.png是我們上傳的包含PHP代碼的照片文件。

2、但是fastcgi在處理’.php’文件時發(fā)現(xiàn)文件并不存在,這時php.ini配置文件中cgi.fix_pathinfo=1 發(fā)揮作用,這項配置用于修復(fù)路徑,如果當(dāng)前路徑不存在則采用上層路徑。為此這里交由fastcgi處理的文件就變成了’/test.png’。

3、 最重要的一點是php-fpm.conf中的security.limit_extensions配置項限制了fastcgi解析文件的類型(即指定什么類型的文件當(dāng)做代碼解析),此項設(shè)置為空的時候才允許fastcgi將’.png’等文件當(dāng)做代碼解析。

注:限制fpm允許解析的腳本擴展名。此設(shè)置可以預(yù)防web服務(wù)器配置的錯誤。應(yīng)當(dāng)限制fpm僅僅解析.php擴展名,阻止惡意用戶使用其他擴展名運行php代碼。默認(rèn)值:.php

三、漏洞環(huán)境搭建和復(fù)現(xiàn)

1、 使用docker搭建漏洞環(huán)境

2、 執(zhí)行如下命令,運行環(huán)境

docker-compose up -d

3、 瀏覽器訪問http://172.17.0.1/

4、上傳一個圖片,burp抓包,修改數(shù)據(jù)包,在末尾添加<?php phpinfo();?>

5、瀏覽器訪問http://172.17.0.1/uploadfiles/3626850d481efd38a8ae8164011f41b2.jpg/a.php

下圖看到成功執(zhí)行了php代碼,說明存在解析漏洞

6、修改php-fpm.conf的配置文件

7、重啟服務(wù)

docker-compose restart

8、瀏覽器再次訪問http://172.17.0.1/uploadfiles/b5f7a062d84869fe4f3af35b79fca50c.jpg/x.php,發(fā)現(xiàn)被拒絕,說明漏洞被修復(fù)

四、漏洞防御

1、 將php.ini文件中的cgi.fix_pathinfo的值設(shè)置為0,這樣php再解析1.php/1.jpg這樣的目錄時,只要1.jpg不存在就會顯示404頁面

2、 php-fpm.conf中的security.limit_extensions后面的值設(shè)置為.php