nginx解析漏洞復現

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

相關文章
相關標籤/搜索