寫在前面
下午的一個電話面試讓我措手不及，壓根就沒準備。不過面試官很好，引導我回答問題，也瞭解很多了知識，但自己不爭氣，給了他一種似懂非懂的感覺，估計是涼了。。。
WEB常見中間件
一開始我聽到這個我人傻掉，啥是中間件，經過面試官引導才知道就是Tomcat、Weblogic、Jboss這些東西，我們經常管web中間件叫做web服務器或者web容器
中間件是提供系統軟件和應用軟件之間連接的軟件，以便於軟件各部件之間的溝通。中間件處在操作系統和更高一級應用程序之間。他充當的功能是：將應用程序運行環境與操作系統隔離，從而實現應用程序開發者不必爲更多系統問題憂慮，而直接關注該應用程序在解決問題上的能力 。容器就是中間件的一種。
也就是說，關於中間件，我們可以理解爲：是一類能夠爲一種或多種應用程序合作互通、資源共享，同時還能夠爲該應用程序提供相關的服務的軟件。（注意：中間件是一類軟件的總稱，不是單獨的一個軟件）
web服務器：IIS、Apache、Nginx、Tomcat、Jboss、Jetty、Weblogic、Webshere、Glasshfish、Lighttpd等
web中間件：Tomcat、Jboss、Jetty、Weblogic、Webshere、Glasshfish等
web容器：IIS(asp容器)、Tomcat(servlet容器)、Jboss(EJB容器)
所以應該是 web服務器>web中間件>web容器
WEB常見中間件漏洞
一、IIS中間組件:
1、PUT漏洞
IIS Server 在 Web 服務擴展中開啓了 WebDAV ，配置了可以寫入的權限，造成任意文件上傳。版本： IIS6.0
1）關閉WebDAV 和寫權限
2、短文件名猜解
IIS的短文件名機制，可以暴力猜解短文件名，訪問構造的某個存在的短文件名，會返回404，訪問構造的某個不存在的短文件名，返回400。
1）升級.net framework
2）修改註冊表禁用短文件名功能
3、遠程代碼執行
在IIS6.0處理PROPFIND指令的時候，由於對url的長度沒有進行有效的長度控制和檢查，導致執行memcpy對虛擬路徑進行構造的時候，引發棧溢出，從而導致遠程代碼執行。
1）關閉 WebDAV 服務
2） 使用相關防護設備
4、解析漏洞
IIS 6.0 在處理含有特殊符號的文件路徑時會出現邏輯錯誤，從而造成文件解析漏洞。
第一種是新建一個名爲 “test.asp” 的目錄，該目錄中的任何文件都被 IIS 當作 asp 程序執行（特殊符號是 “/” ）
第二種是上傳名爲 “test.asp;.jpg” 的文件，雖然該文件真正的後綴名是 “.jpg”, 但由於含有特殊符號 “;” ，仍會被 IIS 當做 asp 程序執行
IIS7.5 文件解析漏洞
若有文件 test.jpg ，訪問時在其後加 /.php ，便可以把 “test.jpg/.php” 交給 php ， php 修理文件路徑 “test.jpg/.php” 得到 ”test.jpg” ，該文件存在，便把該文件作爲 php 程序執行了
1）對新建目錄文件名進行過濾，不允許新建包含‘.’的文件
2）曲線網站後臺新建目錄的功能，不允許新建目錄
3）限制上傳的腳本執行權限，不允許執行腳本
二、Apache中間組件:
1、解析漏洞
Apache默認一個文件可以有多個以點分隔的後綴，當右邊的後綴無法識別（不在mime.tyoes內），則繼續向左識別
1）將AddHandler application/x-httpd-php .php的配置文件刪除。
2、目錄遍歷
由於配置錯誤導致的目錄遍歷
1）修改apache配置文件httpd.conf，找到Options+Indexes+FollowSymLinks +ExecCGI並修改成 Options-Indexes+FollowSymLinks +ExecCGI 並保存；
三、Nginx中間組件:
1、文件解析
對任意文件名，在後面添加/任意文件名.php的解析漏洞，比如原本文件名是test.jpg，可以添加test.jpg/x.php進行解析攻擊。
2、目錄遍歷
Nginx的目錄遍歷與Apache一樣，屬於配置方面的問題，錯誤的配置可到導致目錄遍歷與源碼泄露
1）將/etc/nginx/sites-avaliable/default裏的autoindex on改爲autoindex off
3、CRLF注入
4、目錄穿越
Nginx反向代理，靜態文件存儲在/home/下，而訪問時需要在url中輸入files，配置文件中/files沒有用/閉合，導致可以穿越至上層目錄。
1）Nginx的配置文件/etc/nginx/conf.d/error2.conf的/files使用/閉合。
四、Tomcat中間組件:
1、遠程代碼執行
Tomcat 運行在Windows 主機上，且啓用了 HTTP PUT 請求方法，可通過構造的攻擊請求向服務器上傳包含任意代碼的 JSP 文件，造成任意代碼執行。影響版本： Apache Tomcat 7.0.0 – 7.0.81
1）檢測當前版本是否在影響範圍內，並禁用PUT方法。
2）更新並升級至最新版。
2、war後門文件部署
Tomcat 支持在後臺部署war文件，可以直接將webshell部署到web目錄下。
若後臺管理頁面存在弱口令，則可以通過爆破獲取密碼。
1）在系統上以低權限運行Tomcat應用程序
五、jBoss中間組件:
1、反序列化漏洞
Java序列化，簡而言之就是把java對象轉化爲字節序列的過程。而反序列話則是再把字節序列恢復爲java對象的過程，然而就在這一轉一變得過程中，程序員的過濾不嚴格，就可以導致惡意構造的代碼的實現。
1）不需要http-invoker.sar 組件的用戶可直接刪除此組件；
2）用於對 httpinvoker 組件進行訪問控制。
2、war後門文件部署
jBoss後臺管理頁面存在弱口令，通過爆破獲得賬號密碼。登陸後臺上傳包含後門的war包。
六、WebLogic中間組件:
1、反序列化漏洞
Java序列化，簡而言之就是把java對象轉化爲字節序列的過程。而反序列話則是再把字節序列恢復爲java對象的過程，然而就在這一轉一變得過程中，程序員的過濾不嚴格，就可以導致惡意構造的代碼的實現。
2、SSRF
Weblogic 中存在一個SSRF漏洞，利用該漏洞可以發送任意HTTP請求，進而攻擊內網中redis、fastcgi等脆弱組件。
方法一：以修復的直接方法是將SearchPublicRegistries.jsp直接刪除就好了；
方法二：1）刪除uddiexplorer文件夾 2）限制uddiexplorer應用只能內網訪問
方法三：（常用）
Weblogic服務端請求僞造漏洞出現在uddi組件（所以安裝Weblogic時如果沒有選擇uddi組件那麼就不會有該漏洞），更準確地說是uudi包實現包uddiexplorer.war下的SearchPublicRegistries.jsp。方法二採用的是改後輟的方式，修復步驟如下：
1）將weblogic安裝目錄下的wlserver_10.3/server/lib/uddiexplorer.war做好備份
2）將weblogic安裝目錄下的server/lib/uddiexplorer.war下載
3）用winrar等工具打開uddiexplorer.war
4)將其下的SearchPublicRegistries.jsp重命名爲SearchPublicRegistries.jspx
5）保存後上傳回服務端替換原先的uddiexplorer.war
6）對於多臺主機組成的集羣，針對每臺主機都要做這樣的操作
7）由於每個server的tmp目錄下都有緩存所以修改後要徹底重啓weblogic（即停應用–停server–停控制檯–啓控制檯–啓server–啓應用）
3、任意文件上傳
通過訪問config.do配置頁面，先更改Work Home工作目錄，用有效的已部署的Web應用目錄替換默認的存儲JKS Keystores文件的目錄，之後使用”添加Keystore設置”的功能，可上傳惡意的JSP腳本文件。
方案1：使用Oracle官方通告中的補丁鏈接：http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html；https://support.oracle.com/rs?type=doc&id=2394520.1
方案2:
1）進入Weblogic Server管理控制檯；
2）domain設置中，啓用”生產模式”。
4、war後門文件部署
由於WebLogic後臺存在弱口令，可直接登陸後臺上傳包含後門的war包。
1）防火牆設置端口過濾，也可以設置只允許訪問後臺的IP列表，避免後臺弱口令。
七、其它中間件相關漏洞
1、FastCGI未授權訪問、任意命令執行
服務端使用fastcgi協議並對外網開放9000端口，可以構造fastcgi協議包內容，實現未授權訪問服務端.php文件以及執行任意命令。
1）更改默認端口
2、PHP CGI遠程代碼執行
在apache調用php解釋器解釋.php文件時，會將url參數傳我給php解釋器，如果在url後加傳命令行開關（例如-s、-d 、-c或-dauto_prepend_file%3d/etc/passwd+-n）等參數時，會導致源代碼泄露和任意代碼執行。此漏洞影響php-5.3.12以前的版本，mod方式、fpm方式不受影響。
1）升級php版本；（php-5.3.12以上版本）;
2）在apache上做文章，開啓url過濾，把危險的命令行參數給過濾掉，由於這種方法修補比較簡單，採用比較多吧。
具體做法：
修改http.conf文件，找到<Directory/>增加以下三行
RewriteEngine on
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]
重啓一下apache即可，但是要考慮到，相當於每次request就要進行一次url過濾，如果訪問量大的話，可能會增加apache的負擔。
3）打上php補丁。補丁下載地址:https://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
參考鏈接
https://www.jianshu.com/p/1e82b7a18866
https://www.jianshu.com/p/b8d95de87344