該漏洞與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』等檔案當做**解析。
1、進入vulhub-master的nginx/nginx_parsing_vulnerability目錄下
2、docker啟動環境
dcoker-compose up -d4、在「010editor」上修改hex資料
也可以修改burp提交的資料
5、訪問
如圖，成功解析中的php**，說明系統存在nginx解析漏洞
1、修改限制fpm執行解析的副檔名
2、重新啟動docker環境
3、驗證漏洞已經修復
1、 將php.ini檔案中的cgi.fix_pathinfo的值設定為0,這樣php再解析1.php/1.jpg這樣的目錄時,只要1.jpg不存在就會顯示404頁面
2、 php-fpm.conf中的security.limit_extensions後面的值設定為.php
漏洞復現 Nginx解析漏洞
該漏洞與nginx php版本無關,屬於使用者配置不當造成的解析漏洞。漏洞的本質實際上就是由於fcgi和web server對script路徑級引數的理解不同出現的問題，這是典型的因為跨系統語境不同導致對同乙個請求的不同解釋導致的漏洞。vulhub下環境搭建 2.瀏覽器訪問指定url http 19...
NGINX解析漏洞復現
版本資訊 直接執行sudo docker compose up d啟動環境 訪問localhost uploadfiles nginx.png檢視搭建效果 訪問localhost uploadfiles nginx.png php 在新增 php後，被解析成php檔案，這就是漏洞所在點，也是我們利用...
IIS解析漏洞復現
該解析漏洞形成原因是以 asp命名的資料夾裡面的檔案都會被當作asp檔案解析！首先我們先搭建乙個iis6.0的伺服器，具體搭建方法見文章中還有一些常見的問題也幫大家寫出來了。然後我們建立乙個test.txt的文件裡面寫入hello world，然後修改字尾名將test.txt改為test.jpg 然...