在代碼審計中，按業務流程審計當然是必須的，人工的流程審計的優點是能夠更加全面的發現漏洞，但是缺點是查找漏洞效率低下。如果要定向的查找漏洞，逆向跟蹤變量技術就顯得更加突出，如查找XSS、SQL注入、命令執行……等等，逆向查找變量能夠快速定位漏洞是否存在，本次已SQL注入為例。
前言
本篇文章原本是個PPT，但是一直放着沒有分享，想着閑着也是閑着，那就改成文章發布吧。其實本篇重點在於兩個知識點，一個是代碼審計的逆向思維，另一個是二次攻擊漏洞，其他的我都省略了，就寫幾個重要的吧。對於二次攻擊我也是最近才研究的，研究了點皮毛，錯誤之處還請廣大圈友指正，謝謝。
代碼審計學習之旅
總有人問我代碼審計該怎么學習，該從哪學習，現在統一回復，表示我也不知道。。。
但是對於個人的學習路線來說，路程是漫長而艱辛的，建議學習如下（直接截圖了）：
上面我寫的是“熟悉”，這只是對剛入行的同學說的，作為代碼審計來說，熟練編寫代碼程序是必須的，要想深度化發展，精通一門語言是必經之路。
知識一-變量逆向跟蹤
在代碼審計中，按業務流程審計當然是必須的，人工的流程審計的優點是能夠更加全面的發現漏洞，但是缺點是查找漏洞效率低下。如果要定向的查找漏洞，逆向跟蹤變量技術就顯得更加突出，如查找XSS、SQL注入、命令執行……等等，逆向查找變量能夠快速定位漏洞是否存在，本次已SQL注入為例。
什么是逆向跟蹤 顧名思義，逆向跟蹤就是對變量的逆向查找，開始全局查找出可能存在漏洞的觸發點，然后回溯參數到前端，查看參數來源已經參數傳遞過程中的處理過程。
逆向跟蹤流程 怎樣才能快速定位呢？下面我們一起看下流程。
1、 查看全局文件web.xml
Web.xml主要是配置web項目啟動時加載的信息，比如<listener/>配置你的監聽器，<filter/>配置過濾器，<servlet/>配置你的servlet實現。我們主要查看全局過濾器是否過濾特殊字符已經過濾哪些字符，顯然沒有。
2、 尋找漏洞觸發點
本次以SQL注入為例，SQL注入我就不說了，相關文檔一堆。當我們看到如下形勢的SQL語句，就可能存在SQL注入：
因為安全的寫法是這樣的：
那么，參數“word”可能存在SQL注入漏洞，那我們就回溯“word”參數，看看“word”值到底是怎么傳進來的，回溯到控制層，發現該“word”參數：
追蹤到控制層基本可以確定漏洞存在，並且沒有做相應的過濾，但是為防止“search”方法只是內部調用，繼續回溯“searchword”值，查看是否從前端頁面傳入的：
發現該“searchword”是從前端頁面傳入，因此可以確定漏洞存在，SQLmap截圖如下：
以上就是簡單的逆向跟蹤變量小技巧，什么？太low？沒辦法，就這水平。
知識二-二次漏洞審計
二次漏洞也叫二次攻擊，這方面的資料網上很少，我自己研究了一陣子，發現二次攻擊形勢有很多，也沒明白多少，這次就談談容易明白的二次命令攻擊漏洞，不喜勿噴。
二次漏洞定義：
攻擊者提交的惡意的代碼不是直接通過一個變量提交漏洞函數而是通過變量轉化或者中轉，最終提交到漏洞函數。
二次漏洞特點：
1、常常存在漏洞類型的轉換。
2、常常存在變量中轉。
二次漏洞類型：
1、通過SQL注射漏洞轉化。
2、通過編碼/解碼中轉變量。
3、其它方式。
二次命令攻擊
二次注入漏洞是一種在Web應用程序中廣泛存在的安全漏洞形式。相對於一次注入漏洞而言，二次注入漏洞更難以被發現，但是它卻具有與一次注入攻擊漏洞相同的攻擊威力。
基本流程如下：
1、 構造參數
在數據庫正常的插入、更新等操作中，構造特殊的命令，存儲在數據庫中：
此處只是方便展示漏洞原理，真實代碼中的情況可能復雜的多，此處構造了“cmd”參數為“ipconfig”存儲在數據庫中。
2、 提取變量
當系統內部某處主動調用該參數時，經過了相對應的命令執行參數，就會產生命令攻擊。
經過Runtime函數，執行命令執行：
看到這里肯定有人一臉懵逼，精明的小伙伴就看出問題了，這二次攻擊不是和存儲型跨站一樣么，沒啥區別啊？
然而嚴格來說存儲型跨站並不屬於二次攻擊漏洞，存儲型跨站雖然也是以數據庫作為中轉，但是它執行的方式還是靠人為去點擊才能生效，但是二次攻擊是存儲后主動攻擊，這就是根本的區別。
結論
上面兩點純屬個人理解，有什么錯誤的地方請多多指教。