Java代碼審計-鐵人下載系統

時間 2019-11-10

標籤 java 代碼審計鐵人下載系統欄目 Java 简体版

原文原文鏈接

初學 java 代碼審計，跟着表哥們腳步，走一遍審計流程，就選了個沒有使用 Java 框架的 java 系統，做爲入門。html

目的是爲了熟悉代碼審計流程，尋找漏洞的思路，入門記錄。前端

準備工做

爲了驗證審計出的漏洞效果，仍是要搭建起來系統，否則空說無憑。爲了方便，使用 JspStudy 2016 一體化環境，選擇 tomcat 8.0， jdk 1.8 搭建。查看代碼使用 IDEA，固然，也能夠用 jd-gui，反編譯 class，不過 IDEA 自動就反編譯了，比較方便。java

值得注意的是，使用系統自帶的安裝功能搭建後，打開頁面報錯，過後想起來多是自動導入 sql 文件的路徑程序中寫死了，和本身部署時根目錄位置不同致使的。web

再次經過 install/index.html 頁面從新安裝，則顯示數據庫已經安裝。緣由是 WEB-INF/classes/liuxing_db.properties 中的 db_an=yes 變成了 db_an=no，表示數據庫已經安裝，不會再次安裝。正則表達式

最後發現使用安裝提示裏的第二種手工安裝方法能夠正常安裝系統，人工導入數據庫數據就好了。sql

爲了審計代碼時全局搜索方便，可使用 jad 批量反編譯 class 文件，使用命令如：shell

jad -r -d /path/to/store/java -s java -8 /path/to/classes/files/*/.class數據庫

最後，我將反編譯出來的 java 文件，統一存放在了 WEB-INF/java 目錄下，和 class 文件的原始目錄 WEB-INF/classes 目錄相對應。tomcat

發現漏洞

非框架的代碼審計，按照 前臺——後臺，嚴重——低危，非交互——需交互，跟隨代碼流程儘可能發現高危和易利用漏洞類型爲主。安全

一：重安裝漏洞

像在準備工做中說的同樣，雖然我使用系統自帶的安裝功能失敗了，可是 db_an 參數變成了 no，雖然 /install 目錄的從新安裝頁面沒刪除，但確實使用系統自帶的安裝功能不存在從新安裝漏洞。

跟隨 /install/index.html 頁面，找到 install.jsp 文件，再根據 form action，找到 install_setup.jsp頁面

再根據 install_setup.jsp 頁面上的 import 語句

import="liuxing.util.Install,java.util.*"

找到安裝的主要邏輯源碼，在 WEB-INF/java/liuxing/util/Install.java 中，安裝時會判斷 db_an 的值，yes 能夠安裝，no 不安裝；安裝完後會把值置爲 no，雖然 install 頁面沒刪除，可是已經不可以再次安裝了。

因此，當使用系統自帶的 install 頁面安裝系統時，不存在重安裝漏洞；若是使用手工導入 sql 文件安裝系統，本身又沒有把 db_an 的值寫成 no，沒刪除 install 目錄文件時，存在重安裝漏洞。

二. SQL 注入漏洞

首先嚐試搜索功能，進入 so.jsp，發現將搜索的參數值傳入 Ruanjianguanli 的 so 方法中

進入 WEB-INF/java/liuxing/guanli/Ruanjianguanli.java 文件中，找到 so 方法；發現是調用了 ruanjianDao.so() 函數，

ruanjianDao 是什麼呢？

在 Ruanjianguanli 類的構造函數裏，能夠找到，ruanjianDao 是 RuanjianMySQL 的一個實例，那麼再接着往下跟

而後打開 WEB-INF/java/liuxing/dao/RuanjianMySQL.java 文件，搜索 so 方法，並發現最終是採用預編譯來執行數據庫操做，這裏不存在 SQL 注入漏洞。

public pageModel so(int pageNo, int pageSize, String tiaojian, int lei, String name)

可想而知，有一處用了預編譯，說明就有不少處用了預編譯方式來執行 SQL 語句，基本都沒有 SQL 注入漏洞。而後全局搜索 createStatement 關鍵字，看看有沒有用拼接的SQL語句的。

如上圖，最後也發現幾個能夠注入的地方，可是都須要登陸後臺，在 delete 語句中，能夠用時間盲注，好比：

delete from user where id in('222') or if(ascii(substr(database(),1,1))>107,0,sleep(3));

語句來測試

利用：

可是後臺都登陸了，也不必去糾結這個 SQL 注入漏洞了，進了後臺應該有更容易利用的漏洞。

三. XSS 漏洞

因爲系統較簡單，前臺可以產生 xss 的地方較少，會員註冊後，登陸；能夠在修改郵箱處，用 Payload

""><script>alert(0)</script>

觸發了前端會員的 xss。

並且在後臺管理員修改用戶資料處，嘗試修改該用戶資料，也會觸發此 XSS。

代碼層面，查看 denlu1.jsp 頁面代碼，跟蹤 Userguanli 的 Xiugaiyonghu2 方法，裏面傳入了要修改爲的郵箱和用戶 ID

最終到 WEB-INF/java/liuxing/dao/UserDaoMySQL.java 文件中的 Xiugaiyonghu2 方法中，直接將前端傳過來的 youxiang 值寫入數據庫中，沒有任何安全防禦，從而致使了存儲型 xss。

四. 訪問控制

沒有登陸管理員賬戶，訪問 /admin/admin.jsp 頁面，會被重定向到 /buzai.htm 頁面。打開 admin.jsp 頁面，看看裏面的跳轉邏輯，搜索關鍵字：

RequestDispatcher

getRequestDispatcher

sendRedirect

setHeader

forward

沒有發現跳轉語句，判斷是全局 Filter 的權限認證。查看 WEB-INF/web.xml，發現針對全部 jsp 文件的 AuthFilter 過濾器

順着 filter-class，找到 WEB-INF/java/liuxing/util/AuthFilter.java 文件，分析 doFilter 函數：

關鍵語句在於如下兩個 if 判斷：

若是路徑不是指定的四個安裝系統相關的路徑，會嘗試從數據庫中的 lujing 表中查詢存儲在數據庫中的 web 路徑。

這裏一個坑被我踩到了，沒看代碼的狀況下，認爲找到路徑時 bl 爲 true，沒找到路徑時 bl 爲 false，結果最後解釋不通了。

從新進入 WEB-INF/java/liuxing/util/LuJing.java 文件翻看代碼，發現原來是沒查到路徑才返回 true，找到返回 false。

因此對於數據庫中不存在的管理員路徑 /admin/admin.jsp，返回 true。若是這時候訪問者沒有 session，或者讀不到 admin 的 session，就會返回 true，而後就被重定向到 /buzai.htm 頁面了。

因此，這裏也不存在越權訪問頁面什麼的漏洞。程序用 session 中的 user 和 admin 屬性區分普通用戶和管理員用戶，猜測也沒有垂直越權之類的漏洞，沒有仔細查看。根據 session 中的 id 屬性區分普通用戶，平行越權也放棄了查找。因此不存在訪問控制方面的漏洞。

五. 後臺任意文件上傳漏洞

在"其它管理"—"添加友情連接"處、"軟件管理"—"軟件發佈"頁面，均可以上傳文件，在 web.xml 中或者順着 jsp 頁面調用尋找，都可以找到具體的邏輯代碼

內部代碼看起來都是同樣的，以 WEB-INF/java/liuxing/util/shangchuan2.java 文件爲例，關鍵代碼以下：

其中會判斷上傳的文件名，要符合正則表達式 ".+\\\\(.+)$"，纔可以正常上傳。即形似 xxx\\xx 的文件名，估計是爲了匹配 Windows 路徑中的 \\，好比 C:\\a.jpg。定義了內部禁止的後綴名 ".exe", ".com", ".cgi", ".asp"，這就是惟一的過濾方式了。

繼續往下看，寫文件時，關鍵的一句代碼：