環境部署

1. 下載源代碼，使用IDEA進行部署，項目pom.xml進行maven依賴包添加、配置數據庫賬號密碼、配置開啟端口后即可使用tomcat7插件運行項目。
2. 搭建過程遇見兩個坑點：

mysql建議直接使用5.5.*版本的，高版本的會因為mysql的默認配置需要額外配置而遇見各種問題，雖然最后都能搭建成功，但是直接使用低版本的就無需額外配置。

項目路徑建議直接使用 http://IP:port 形式，后面不要配置額外的路徑，加入額外項目配置后雖然可以部署成功，但是會導致一些頁面或者圖片加載不成功。

3. 進行代碼審計時，記得需要額外把\src\main\webapp\WEB-INF\lib\目錄下的jar包反編譯后再進行代碼審計，因為使用IDEA進行源碼關鍵字搜索時不會搜索jar包中的代碼，我審計之前就沒有注意到項目下的這個目錄，導致前面審計過程中某些功能找不到源代碼。

項目結構分析

這是一個SSM（即Spring Framework、Spring MVC、MyBatis）架構項目。

百科是這樣介紹的：

• pom.xml：審計maven項目首先應該查看pom.xm，通過查看此文件可以知道項目用了哪些組件及組件版本，這樣可以快速查看組件對應的版本是否有漏洞。

觀察到項目使用了log4j 且版本為1.2.17，此版本存在反序列化漏洞CVE-2019-17571（經過分析，不存在此漏洞，因為本項目未使用產生此漏洞的類即SocketNode類）。

還使用了druid 1.0.1 組件，可以找一些未授權接口（經過測試未發現此組件產生的未授權）。

mybatis 3.2.7 組件存在反序列化漏洞CVE-2020-26945（經過分析，不存在此漏洞，因為此項目未開啟mybatis二級緩存功能）。

• web.xml：程序啟動時會先加載這個文件，此文件用來配置Filter、Listener、Servlet。此文件需要重點關注Filter過濾器的全局配置。此項目只配置了兩個全局的過濾器且這兩個過濾器都未對輸入輸出進行轉義之類的字符處理，所以未配置全局的XSS過濾。

• applicationContext.xml： spring的默認配置文件，當容器啟動時找不到其他指定配置文檔時，將加載這個配置文件，此文件也包含引用其他的配置文件。

• spring-mvc.xml：此文件主要的工作是：啟動注解、掃描controller包注解；靜態資源映射；視圖解析（defaultViewResolver）；文件上傳（multipartResolver）;返回消息json配置。



• web項目啟動時，讀取web.xml配置文件，首先解析的是applicationContext.xml文件，其次才是sping-mvc.xml文件。
• Interceptor：攔截器，用于攔截用戶請求并進行相應的處理。比如通過它來進行權限驗證，或者是來判斷用戶是否登陸，或者是像12306 那樣子判斷當前時間是否是購票時間。此項目有3個攔截器，分別對前臺用戶、后臺用戶、網站配置管理處的用戶是否登錄與權限做相應處理。

代碼審計

前臺找回密碼處驗證碼重復利用

直接在代碼中搜索關鍵字驗證碼，對相關代碼進行分析。

此處是找回密碼功能，先后獲取客戶端與服務端驗證碼進行校驗，校驗成功后進入校驗郵箱是否注冊，若未注冊則直接返回結果，未刪除服務端中的舊驗證碼，所以此處可對驗證碼重復使用來爆破出已經注冊的郵箱。

繼續分析可知，郵箱存在且重置密碼之后才清除服務端中的驗證碼。因為前臺登錄處無驗證碼，所以此處可配合登錄處繼續密碼爆破。

但是經過分析，后臺管理員登錄處就不存在驗證碼重復利用，因為驗證碼校驗正確后就會立馬進行清除。

XSS

開頭已經分析未發現全局的XSS過濾器，所以直接注冊賬號進行登錄，見框就插入XSS payload。

在問答功能下的我要提問功能處發現存儲型XSS。

此處只有標題有XSS而內容無XSS，找到對應的入口進行分析原因，questionsService.addQuestions()為添加問答方法，追蹤此方法

QuestionsController-->QuestionsService-->QuestionsServiceImpl-->QuestionsDao-->QuestionsDaoImpl-->QuestionsMapper

根據追蹤過程分析未做字符過濾就直接保存到數據庫中。并且標題和內容都保存數據庫中。

由此可知，存儲過程標題和內容未做差異化處理，說明在輸出的時候對內容進行了過濾，繼續分析輸出部分。由以上可知,存在XSS的url為http://127.0.0.1:8080/question/list。

直接在*.jsp文件中搜索question/list找到對應的輸出點。很明顯標題處是直接拼接數據庫中的值并未使用標簽包裹，而內容處則使用了<c:out>標簽。在jsp文件中，使用<c:out>標簽是直接對代碼進行輸出而不當成js代碼執行。

自此，產生XSS的來龍去脈都已經知道了，所以輸出變量時，沒有使用<c:out>標簽進行防護的都會產生XSS，經分析其他還有多處有XSS。

SQL注入

因為使用的時mybatis框架，所以直接在*Mapper.xml文件中搜索${即可。

發現存在多處使用${}進行拼接的地方，選擇一處進行分析

找到對應的controller層入口。此處為后臺管理員用戶刪除文章功能處。

抓取請求包直接使用sqlmap爆破即可。

其他還有幾處也存在sql注入。類似分析即可。有幾處因為是直接拼接路徑中的字符作為參數的，所以這種情況即使使用${}也不會造成sql注入。

前臺用戶橫向越權

在用戶修改個人資料時，直接抓包修改 user.userId參數值即可越權登錄到其他存在的用戶。

分析代碼可知，未對用戶進行判斷就直接把用戶信息更新到數據庫中，更新數據庫中后直接使用userid進行自動重新登錄從而可導致直接登錄其他用戶界面。

CSRF

后臺管理員創建用戶處存在CSRF漏洞，攻擊者可結合此系統的XSS漏洞構造惡意代碼從而導致創建系統管理員用戶。

可用burpsuite自帶的CSRF工具生成payload進行測試。

從代碼處可知，未對請求體校驗Referer字段，也無token機制。因此可造成CSRF。

前臺文件上傳getshell

前置知識點

jspx：以xml語法來書寫jsp的文件，自定義的映射類型，jspx=jsp+xml；jspx文件本身符合xml的規范，但是它本質又是一個jsp文件，所以在所有jsp里面能夠做到的事情在jspx里同樣可以做到。

tomcat的web.xml中org.apache.jasper.servlet.Jspservlet配置關于jsp服務的解析，默認是都會解析jsp和jspx。

此處漏洞發生在前臺用戶上傳頭像處。

直接找到源代碼進行分析，源碼在\src\main\webapp\WEB-INF\lib\inxedu-jar.jar包中。

此處的fileType即為前端傳入的文件類型后綴，分析代碼可知，此處只過濾了jsp文件其他文件可隨意上傳，可以上傳html文件造成XSS漏洞，由于此項目使用tomcat，所以可以上傳jspx文件getshell。

使用哥斯拉工具生成jspx木馬上傳文件，上傳成功。

連接成功。