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