前言
上篇文章的釋出引起了很多讀者的浏覽，有很多讀者也催更希望讀到續集，作者也收獲到讀者的鼓勵，說明這條路線對大家有幫助，是有意義的。是以，今天作者将繼續闡述在審計Java代碼時的思路。
概述
上篇文章所講的SQL注入和中間件漏洞的審計，其實在大多數的情況下SQL注入是不會存在的，兩方面原因。注入存在的曆史太過悠久，以至于人盡皆知。2.大多數Java開發在入職面試時，考官都會将這個細節當作問題抛給開發者。是以要是靠這個漏洞，那大黑闊們估計是要餓死的。今天帶來的是越權漏洞的審計，這個漏洞能拿下百分之八十的JavaWeb代碼。
越權漏洞的前世今生
越權漏洞分為垂直越權和水準越權，在大多數場景中都存在水準越權，是以先跟讀者講述水準越權。
大多數功能當中，删除功能一向是水準越權的“重災區”。開發在實作删除功能時，前端将id号傳給背景，背景将此id的資料進行删除。這麼想确實沒什麼問題，但是問題出就出在删除上。原因在于，當背景拿到id時不去判斷目前id是否屬于登入使用者，直接将id資料進行删除，這就導緻了越權漏洞的産生。
下面上代碼
這一套删除執行鍊中，并沒有對前端傳來的id進行任何操作，直接進行删除。熟不知，在前端向背景傳送id的過程中，id值被篡改修改成其他使用者下存在的記錄id，将其他使用者的記錄進行删除，這就造成了水準越權的産生。
水準越權往往被定性為低微漏洞，這裡作者就要替越權發聲了，從某種角度來講，如果滲透者發現了一個這樣的越權漏洞，完全可以編寫一個腳本。腳本的内容為循環請求這樣的接口，參數id為從1依次遞增。背景執行這樣的删除操作，可想而知，典型的删庫。
FREEBUF平台爸爸，某處存在此水準越權。發生地點不透露，但足以說明存在率(多有得罪)。
看到這裡，想必很多讀者有知道了一個“獲得銀手镯”的方法，作者建議遇到這種漏洞自己建立一個使用者進行測試即可，切勿使用這種方式擴大“戰果”。此假設隻是從角度的問題證明越權的危害性。
防禦：這麼大的漏洞為什麼這麼多Java開發者不去修複，存在率竟如此之高？如果讀者是一名開發那麼仔細閱讀下文(提醒)
原因有二：1.是後端開發者完全想不到在前端向後端傳值時會被篡改沒太過依賴前端。(所有的前端傳參必須零信任)2.如果後端拿到前端參數的id，再去查詢此id是否屬于目前使用者，意味着還需要走一條sql，無疑是對資料庫性能的又一次損耗，對開發成本的又一次增加。解鈴還須系鈴人，問題産生的關鍵就在于id，是以作者建議在生成id時不要采用從1開始依次遞增的方法，采用雪花算法生成id。下面上代碼
這樣的id有什麼好處？當滲透者暴力猜解資料庫進行删庫操作時，此id無法被猜解，因為資料量太過龐大，此處不在贅述雪花算法。但是，此方法隻能在某種程度上解決這樣的問題，如果滲透者真的頭鐵硬試，我們毫無辦法。(擡一手，留口飯吃)。
下面講垂直越權，垂直越權完全依靠前端頁面顯示作為使用者點選的限制，挖掘此處漏洞滲透者必須擁有高權限賬号，還有一個低權限賬号。使用低權限賬号調用高權限才有的接口進行測試。
講到這裡，作者覺得這個漏洞大家不必挖掘，因為能産生這種漏洞不是開發者技術和邏輯的問題。完全是開發者懶的問題，懶到不想寫代碼。而且垂直越權大多數開發者選用Apache Shiro和springSecurity架構進行權限判定。滲透者可以更關注shiro的兩個漏洞在垂直越權上。
這種漏洞除了開發者态度有問題基本不可能發生，如果滲透者發現過此類型的洞可以将開發者定性為“菜雞”，并且拉出去“砍死一百次”。
結尾
講到這裡，關于JavaWeb審計的不需要代碼基礎的洞講完了，接下來的文章當中講述JavaWeb中的邏輯漏洞，這個區域才是Java漏洞的真正聚集地。但是意味着讀者需要一定的Java功底才能繼續跟進，如果讀者想繼續學習Java審計這一系列，請跟我一起學習Java開發吧~，我是小楊，感謝大家閱讀關注。