我是啊鋒，一個努力的學渣，作為一個剛進入安全大門的小白，我希望能把自己所學到的東西總結出來，分享到部落格上，可以一起進步，一起交流，一起學習。
Apache 換行解析漏洞
其2.4.0~2.4.29版本中存在一個解析漏洞，在解析PHP時，1.php\x0A将被按照PHP字尾進行解
析，導緻繞過一些伺服器的安全政策。
例子如下：
正常上傳.php檔案上傳不成功，burp抓包後發送到Repeater然後hex在置右鍵-Insert byte0d前加一個0a，然後send，即可繞過上傳
在頁面通路http://192.168.0.99:8080/feng.php%0a
Apache未知字尾名解析漏洞
影響版本Apache 1.x和Apache 2.x
Apache在解析檔案時有一個原則：當碰到不認識的擴充名時，将會從後面向前解析，直到碰到認識的擴充名為止。
例如feng.php.QWE.ABC
Apache在處理時，先讀取最後一個字尾，為ABC不認識，繼續往左讀取QWE不認識，讀到php能識别這個字尾，于是就把feng.php.QWE.ABC當成是feng.php檔案來解析，若是所有字尾都看完了沒有一個認識怎麼辦？此時就會把該檔案當做預設類型進行處理了，一般來說，預設類型是text/plain。
Apache多字尾名解析漏洞
Apache HTTPD 支援一個檔案擁有多個字尾，并為不同字尾執行不同的指令。比如，如下配置檔案：
AddType text/html .html
AddLanguage zh-CN .cn
其給.html字尾增加了media-type，值為text/html；給.cn字尾增加了語言，值為zh-CN。此時，如果使用者請求檔案index.cn.html，他将傳回一個中文的html頁面。
以上就是Apache多字尾的特性。如果運維人員給.php字尾增加了處理器：
AddHandler application/x-httpd-php .php
那麼，在有多個字尾的情況下，隻要一個檔案含有.php字尾的檔案即将被識别成PHP檔案，沒必要是最後一個字尾。利用這個特性，将會造成一個可以繞過上傳白名單的解析漏洞。
例如上傳feng.php檔案上傳失敗，抓包後修改添加字尾.jpeg，然後再上傳，即可繞過，上傳成功且傳回了位址
直接通路IP/uploadfiles/feng.php.jpeg
Apache罕見字尾
phtml、pht、php3、php4和php5都是Apache和php認可的php程式的檔案字尾
IIS 6.0解析利用方法
- 目錄解析
/xx.asp/xx.jpg
若檔案夾的名字字尾為 .asp、.asa，其目錄内的任何擴充名的檔案都被IIS當作asp檔案來解析并執行。
例如建立目錄 abc.asp，那麼
/abc.asp/1.jpg
1.jpg将被當作1.asp檔案來執行。不管你上傳後你的圖檔改不改名都能拿shell了。
- 檔案解析
在IIS6.0下，分号後面的不被解析，例如
abc.asp;.jpg
會被伺服器看成是abc.asp
原理大抵是IIS 5.x/6.0在從檔案路徑中讀取檔案字尾時，遇到一個“.”後，便進入了一種截斷狀态，在該狀态下遇到特殊符号 “/”和“;”，都會進行截斷，隻保留特殊符号前的部分，即“.asp”，進而認為檔案字尾為“.asp”。
- 預設解析
IIS6.0 預設的可執行檔案除了asp還包含這三種預設解析：/xx.asa /xx.cer /xx.cdx
原因：由于在 IIS 預設配置中，這幾個字尾預設由 asp.dll 來解析，是以執行權限和 .asp 一摸一樣，你可在配置中自行删除該字尾，以防止安全隐患
此處可聯系利用目錄解析漏洞 /xx.asa/xx.jpg 或 /xx.cer/xx.jpg 或 xx.asa;.jpg
- IIS 7.0/IIS 7.5/ Nginx <8.03畸形解析漏洞
前提：預設Fast-CGI開啟狀況下，在一個檔案路徑(/xx.jpg)後面加上/xx.php會将
/xx.jpg/xx.php 解析為 php 檔案。
在某些使用有漏洞的網站中，通路http://xxx.xxx.xxx/1.jpg/1.php，此時的1.jpg會被當作PHP腳本來解析,但是1.php是不存在的。
這就意味着攻擊者可以上傳合法的“圖檔”（圖檔木馬）然後在URL後面加上“/1.php”，就可以獲得網站的WebShell，菜刀連接配接：http://xxx.xxx.xxx/1.jpg/1.php
Windows作業系統檔案命名規則
Windows作業系統中，檔案名不能以空格或“.”開頭，也不能以空格或“.”結尾。當把一個檔案命名為以空格或“.”開頭或結尾時，會自動地去掉開頭和結尾處的空格和“.”。利用此特性，也可能造成“檔案解析漏洞”。
此外，Windows作業系統中的檔案名是不區分大小寫的，xxx.asp和xxx.Asp、xxx.php和xxx.PHp具有同樣的效果。
Nginx <8.03 空位元組代碼執行漏洞
漏洞原理：
該漏洞與Nginx、php版本無關，屬于使用者配置不當造成的解析漏洞。
Nginx預設是以Fast-CGI的方式支援PHP解析的，普遍的做法是在Nginx配置檔案中通過正則比對設定SCRIPT_FILENAME。當通路www.xx.com/phpinfo.jpg/1.php這個URL時，$fastcgi_script_name會被設定為“phpinfo.jpg/1.php”，然後構造成SCRIPT_FILENAME傳遞給PHP CGI，但是PHP為什麼會接受這樣的參數，并将phpinfo.jpg作為PHP檔案解析呢?這就要說到fix_pathinfo這個選項了。 如果開啟了這個選項，那麼就會觸發在PHP中的如下邏輯：
PHP會認為SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，是以就會将phpinfo.jpg作為PHP檔案來解析了
漏洞利用形式
www.xxxx.com/UploadFiles/p_w_picpath/1.jpg/1.php
www.xxxx.com/UploadFiles/p_w_picpath/1.jpg%00.php
www.xxxx.com/UploadFiles/p_w_picpath/1.jpg/%20\0.php
Nginx <=0.8.37
在Fast-CGI關閉的情況下，Nginx <=0.8.37 依然存在解析漏洞
在一個檔案路徑(/xx.jpg)後面加上.php會将 /xx.jpg.php 解析為 php 檔案。
以上是我暫時所總結的解析漏洞，後續會逐漸添加
參考文章：
https://blog.werner.wiki/file-resolution-vulnerability-apache/
https://blog.werner.wiki/file-resolution-vulnerability-iis/
https://blog.51cto.com/wt7315/1865580