前言

上篇文章的發布引起了很多讀者的瀏覽，有很多讀者也催更希望讀到續集，作者也收獲到讀者的鼓勵，說明這條路線對大家有幫助，是有意義的。所以，今天作者將繼續闡述在審計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開發吧~，我是小楊，感謝大家閱讀關注。

總結

以上是生活随笔為你收集整理的javaweb 图书管理系统完整代码_看一名Java开发人员以红队思维五分钟审计一套代码（续）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。