一、漏洞描述
該漏洞與nginx、php版本無關,屬於用戶配置不當造成的解析漏洞
二、漏洞原理
1、 由於nginx.conf的如下配置導致nginx把以’.php’結尾的文件交給fastcgi處理,為此可以構造http://ip/uploadfiles/test.png/.php (url結尾不一定是‘.php’,任何服務器端不存在的php文件均可,比如’a.php’),其中test.png是我們上傳的包含PHP代碼的圖片文件。
2、但是fastcgi在處理’.php’文件時發現文件並不存在,這時php.ini配置文件中cgi.fix_pathinfo=1 發揮作用,這項配置用於修復路徑,如果當前路徑不存在則采用上層路徑。為此這里交由fastcgi處理的文件就變成了’/test.png’。
3、 最重要的一點是php-fpm.conf中的security.limit_extensions配置項限制了fastcgi解析文件的類型(即指定什么類型的文件當做代碼解析),此項設置為空的時候才允許fastcgi將’.png’等文件當做代碼解析。
注:限制fpm允許解析的腳本擴展名。此設置可以預防web服務器配置的錯誤。應當限制fpm僅僅解析.php擴展名,阻止惡意用戶使用其他擴展名運行php代碼。默認值:.php
三、漏洞環境搭建和復現
1、 使用docker搭建漏洞環境
2、 執行如下命令,運行環境
docker-compose up -d
3、 瀏覽器訪問http://172.17.0.1/
4、上傳一個圖片,burp抓包,修改數據包,在末尾添加<?php phpinfo();?>
5、瀏覽器訪問http://172.17.0.1/uploadfiles/3626850d481efd38a8ae8164011f41b2.jpg/a.php
下圖看到成功執行了php代碼,說明存在解析漏洞
6、修改php-fpm.conf的配置文件
7、重啟服務
docker-compose restart
8、瀏覽器再次訪問http://172.17.0.1/uploadfiles/b5f7a062d84869fe4f3af35b79fca50c.jpg/x.php,發現被拒絕,說明漏洞被修復
四、漏洞防御
1、 將php.ini文件中的cgi.fix_pathinfo的值設置為0,這樣php再解析1.php/1.jpg這樣的目錄時,只要1.jpg不存在就會顯示404頁面
2、 php-fpm.conf中的security.limit_extensions后面的值設置為.php