Java代碼審計連載之—添油加醋

在代碼審計中，按業務流程審計固然是必須的，人工的流程審計的優勢是可以更加全面的發現漏洞，可是缺點是查找漏洞效率低下。若是要定向的查找漏洞，逆向跟蹤變量技術就顯得更加突出，如查找XSS、SQL注入、命令執行……等等，逆向查找變量可以快速定位漏洞是否存在，本次已SQL注入爲例。

本文做者：黑客小平哥，i春秋首發

前言

本篇文章本來是個PPT，可是一直放着沒有分享，想着閒着也是閒着，那就改爲文章發佈吧。其實本篇重點在於兩個知識點，一個是代碼審計的逆向思惟，另外一個是二次攻擊漏洞，其餘的我都省略了，就寫幾個重要的吧。對於二次攻擊我也是最近才研究的，研究了點皮毛，錯誤之處還請廣大圈友指正，謝謝。

代碼審計學習之旅

總有人問我代碼審計該怎麼學習，該從哪學習，如今統一回復，表示我也不知道。。。

可是對於我的的學習路線來講，路程是漫長而艱辛的，建議學習以下（直接截圖了）：

上面我寫的是「熟悉」，這只是對剛入行的同窗說的，做爲代碼審計來講，熟練編寫代碼程序是必須的，要想深度化發展，精通一門語言是必經之路。

知識一-變量逆向跟蹤

在代碼審計中，按業務流程審計固然是必須的，人工的流程審計的優勢是可以更加全面的發現漏洞，可是缺點是查找漏洞效率低下。若是要定向的查找漏洞，逆向跟蹤變量技術就顯得更加突出，如查找XSS、SQL注入、命令執行……等等，逆向查找變量可以快速定位漏洞是否存在，本次已SQL注入爲例。

什麼是逆向跟蹤 顧名思義，逆向跟蹤就是對變量的逆向查找，開始全局查找出可能存在漏洞的觸發點，而後回溯參數到前端，查看參數來源已經參數傳遞過程當中的處理過程。

逆向跟蹤流程 怎樣才能快速定位呢？下面咱們一塊兒看下流程。

一、 查看全局文件web.xml

Web.xml主要是配置web項目啓動時加載的信息，好比<listener/>配置你的監聽器，<filter/>配置過濾器，<servlet/>配置你的servlet實現。咱們主要查看全局過濾器是否過濾特殊字符已通過濾哪些字符，顯然沒有。

二、 尋找漏洞觸發點

本次以SQL注入爲例，SQL注入我就不說了，相關文檔一堆。當咱們看到以下形勢的SQL語句，就可能存在SQL注入：

由於安全的寫法是這樣的：

那麼，參數「word」可能存在SQL注入漏洞，那咱們就回溯「word」參數，看看「word」值究竟是怎麼傳進來的，回溯到控制層，發現該「word」參數：

追蹤到控制層基本能夠肯定漏洞存在，而且沒有作相應的過濾，可是爲防止「search」方法只是內部調用，繼續回溯「searchword」值，查看是否從前端頁面傳入的：

發現該「searchword」是從前端頁面傳入，所以能夠肯定漏洞存在，SQLmap截圖以下：

以上就是簡單的逆向跟蹤變量小技巧，什麼？太low？沒辦法，就這水平。
方面的資料網上不多，我本身研究了一陣子，發現二次攻擊形勢有不少，也沒明白多少，此次就談談容易明白的二次命令攻擊漏洞，不喜勿噴。

二次漏洞定義：

攻擊者提交的惡意的代碼不是直接經過一個變量提交漏洞函數而是經過變量轉化或者中轉，最終提交到漏洞函數。

二次漏洞特色：

一、經常存在漏洞類型的轉換。

二、經常存在變量中轉。

二次漏洞類型：

一、經過SQL注射漏洞轉化。

二、經過編碼/解碼中轉變量。

三、其它方式。

二次命令攻擊

二次注入漏洞是一種在Web應用程序中普遍存在的安全漏洞形式。相對於一次注入漏洞而言，二次注入漏洞更難以被發現，可是它卻具備與一次注入攻擊漏洞相同的攻擊威力。

基本流程以下：

一、 構造參數

在數據庫正常的插入、更新等操做中，構造特殊的命令，存儲在數據庫中：

此處只是方便展現漏洞原理，真實代碼中的狀況可能複雜的多，此處構造了「cmd」參數爲「ipconfig」存儲在數據庫中。

二、 提取變量

當系統內部某處主動調用該參數時，通過了相對應的命令執行參數，就會產生命令攻擊。

通過Runtime函數，執行命令執行：

看到這裏確定有人一臉懵逼，精明的小夥伴就看出問題了，這二次攻擊不是和存儲型跨站同樣麼，沒啥區別啊？

然而嚴格來講存儲型跨站並不屬於二次攻擊漏洞，存儲型跨站雖然也是以數據庫做爲中轉，可是它執行的方式仍是靠人爲去點擊才能生效，可是二次攻擊是存儲後主動攻擊，這就是根本的區別。
結論

上面兩點純屬我的理解，有什麼錯誤的地方請多多指教。