今天看書看到其中提到的一個漏洞，那就是Nginx+PHP的服務器中，如果PHP的配置里 cgi.fix_pathinfo=1 那么就會產生一個漏洞。這個配置默認是1的，設為0會導致很多MVC框架（如Thinkphp）都無法運行。這個漏洞就是比如 localhost/img/1.jpg 是正常地訪問一張圖片，而 localhost/img/1.jpg/1.php 卻會把這張圖片作為PHP文件來執行！如下圖，應該是404 NotFound 才對的，它卻顯示說是有語法錯誤。
好家伙，既然有漏洞那就嘗試怎么攻擊吧。先看思路：首先弄一個很小的JPG文件方便修改，然后在JPG文件中插入代碼，再上傳，最后在瀏覽器打開。
第一步，小的JPG文件當然是直接用Photoshop做一個了；
幾個像素就夠了。樣子隨便，你喜歡就好。
第二步，在JPG中插入代碼，這個要用到二進制編輯器；
JPG圖片如何修改成為可以執行PHP代碼？這里以實驗目的，以成功執行一個輸出PHP運行環境信息的函數 phpinfo() 為例。
首先這里編輯圖片的話並不是說用畫圖或者Phtoshop之類的圖形軟件，這次要用到的軟件叫做 二進制編輯器，其中我用的這款名叫 Bz.exe，打開圖片文件如下圖
不要被嚇到，就是16進制的數而已，右邊顯示的是對應的ASCII碼，我們直接改右邊就可以了。通過幾個JPG文件的對比發現，從第二行開始就可以自行修改了，於是開工修改，注意不要使用退格刪除導致長度縮短，要用字符替換的，否則會造成文件格式損壞。修改成如下圖，保存到本地的圖片文件夾中，在本地測試。
！注意不要使用退格刪除導致長度縮短，圖片損壞，比如像下圖第一個的那種改了之后不顯示縮略圖的就已經是損壞了，損壞的圖片可能會在上傳的時候被攔截掉。
改好之后再本地測試，
似乎還不行，看起來應該是后面有一些PHP語法錯誤，那就簡單粗暴，修改成下圖這樣，即是把后面的內容全部使用/* 來注釋掉 結尾用 */ 閉合注釋，當然結尾的注釋不加也可以，只會多顯示一個“Unterminated comment starting”的警告而已。建議不需要改成*/結尾，否則修改后的圖片在Photoshop中會打不開（因為FF D9是jpg文件的標准結尾）。
可以看到，已經可以執行PHP代碼了。本地攻擊演練成功！
第三步，上傳，因為上傳的確實是jpg格式的文件，網站幾乎無法識別和攔截；
第四步，在瀏覽器打開，Hello World！
這一步成功需要以下幾個條件：
1）服務器是Nginx+PHP並且配置里是cgi.fix_pathinfo=1。這個是不是nginx一般可以在Http響應頭里找到相應服務器信息，用Firebug等瀏覽器調試工具就能看到，至於這個配置項是不是1一般很難看出，就暫且當它是吧～～；
2）網站沒有屏蔽上傳目錄的腳本執行權限。這個就比較難啰，用得上Nginx的公司基本上都有專門的運維，如果這點安全意識都沒有，運維可以回家了；如果是小公司什么都不懂就冒然使用Nginx那恭喜；
3）可以訪問原圖，這個看機遇，有的可以有的沒有；
所以，慢慢找吧，也許可遇而不可求；
｜++ 此漏洞的功擊效果與“文件上傳漏洞”相當
∞、防御建議
1）使用Apache、IIS等成熟久經考驗的服務器軟件，在動態語言的支持上，Nginx還是太年經了。你應該也偶爾會見到有些網站掛掉了顯示個nginx錯誤出來，卻極少見網站掛掉顯示不是nginx的(未備案，過期欠費 等等除外)。
2）上傳目錄、靜態資源（CSS/JS/圖片等）目錄，都設置好屏蔽PHP執行權限。例如使用Apache服務器的在相應目錄下放一個 .htaccess 文件，里面寫上
<FilesMatch "(?i:\.php)$">
Deny from all
</FilesMatch>
3）可以不提供原圖訪問，所有圖片輸出時都經過程序處理，也可以在上傳存儲時就處理一遍根本不保存原圖；
4）圖片使用不同的服務器，這樣可以與業務代碼數據完全隔離，即使圖片服務器被黑了，也不會泄漏多少信息；
5）如鳥哥所說的把那個配置項設為0，此舉慎用，除非你十分確定該服務器上的所有項目都不會因此而無法運行。