nginx解析漏洞復現

一、漏洞描述

該漏洞與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