0x01 等保測評項

GBT 22239-2019《信息安全技術網絡安全等級保護基本要求》中，8.1.4.2安全計算環境—訪問控制項中要求包括：

a）應對登錄的用戶分配賬戶和權限；

b）應重命名或刪除默認賬戶，修改默認賬戶的默認口令；

c）應及時刪除或停用多余的、過期的賬戶，避免共享賬戶的存在；

d）應授予管理用戶所需的最小權限，實現管理用戶的權限分離；

e）應由授權主體配置訪問控制策略，訪問控制策略規定主體對客體的訪問規則；

f）訪問控制的粒度應達到主體為用戶級或進程級，客體為文件、數據庫表級；

g）應對重要主體和客體設置安全標記，并控制主體對有安全標記信息資源的訪問。

越權訪問對應訪問控制項中要求e），所以安全控制點為訪問控制e。

GBT 28448-2019《信息安全技術網絡安全等級保護測評要求》中，測評單元（L3-CES1-09）

該測評單元包括以下要求:

a）測評指標：應由授權主體配置訪問控制策略，訪問控制策略規定主體對客體的訪問規則。

b）測評對象：終端和服務器等設備中的操作系統（包括宿主機和虛擬機操作系統）、網絡設備（包括虛擬網絡設備）、安全設備（包括虛擬安全設備）、移動終端、移動終端管理系統、移動終端管理客戶端、業務應用系統、數據庫管理系統、中間件和系統附案例軟件及系統設計文檔等。

c）測評實施包括以下內容：

1）應核查是否由授權主體（如管理用戶）負責配置訪問控制策略；

2）應核查授權主體是否一句安全策略配置了主體對客體的訪問規則；

3）應測試驗證用戶是否由可越權訪問情形。

d）單元判定：如果1）～3）均為肯定，則符合本測評單元指標要求，否則不符合或部分符合本測評單元指標要求。

越權訪問漏洞屬于測評單元（L3-CES1-09）中測評實施的第3項，故定測評單元為L3-CES1-09.3。

0x02 測試內容

測試系統是否存在特權等級升級到另一個特權等級或同等級其他賬戶的問題。

0x03 漏洞原理

原理

越權訪問是Web應用程序中一種常見的漏洞，由于其存在范圍廣、危害大，被OWASP列為Web應用十大安全隱患的第二名。該漏洞是指應用程序在檢查授權時存在紕漏，使得攻擊者在獲得低權限賬戶后，利用一些方式繞過權限檢查，訪問或者操作其他用戶或者更高權限。

越權漏洞的成因主要是因為開發人員在后臺使用了不合理的校驗規則。在對數據進行增、刪、改、查時對客戶端請求的數據過分相信而遺漏了權限的判定，一旦權限驗證不充分，就易導致越權漏洞。這點與SQL注入漏洞、XSS等漏洞很相像，都是由開發人員對請求的數據沒有做到更全的防御導致的風險問題。

一般越權漏洞容易出現在需要驗證當前身份的頁面，如用戶登錄、操作數據、提現、修改個人資料、發送私信、上傳圖片、上傳表單、下單、充值、找回密碼等處。當用戶對權限頁面內的信息進行這些操作時，后臺需要對當前用戶的權限進行校驗，看其是否具備操作的權限，從而給出響應，而如果校驗的規則過于簡單則容易出現越權漏洞。

分類

這類漏洞往往很難通過工具進行自動化檢測，屬于邏輯漏洞中的一種。越權漏洞一般分為水平越權和垂直越權、交叉越權。

但從廣義上來講還包括一種“未授權漏洞”，這種漏洞類似于越權漏洞的垂直越權，攻擊者沒有獲取到登錄權限或未授權的情況下，不需要登錄即可通過輸入網站控制臺地址直接訪問進行操作，但此篇文章只講水平越權與垂直越權，后續會專門寫一篇未授權訪問漏洞文章。

越權分類

水平越權：

又稱橫向越權，這是一種“基于數據的訪問控制”設計缺陷引起的漏洞。由于服務器端在接收到請求數據進行操作時沒有判斷數據的所屬人/所屬部門而導致的越權數據訪問漏洞，也就是相同權限的不同用戶之間可以互相訪問數據以及執行其他用戶的功能等。

水平越權

垂直越權：

又稱縱向越權，這是一種“基于URL的訪問控制”設計缺陷引起的漏洞，由于后臺應用沒有做權限控制，或僅僅在菜單、按鈕上做了權限控制，導致惡意用戶只要猜測其他管理頁面的URL或者敏感的參數信息，就可以訪問或控制其他角色擁有的數據或頁面，達到權限提升的目的。也就是低權限用戶可訪問高權限用戶的數據以及執行高權限用戶功能等。

垂直越權

交叉越權：

既可以水平越權又可以垂直越權。

0x04 代碼示例

以下代碼中第8行沒有對傳入的ID進行校驗，ID代表用戶，攻擊者直接傳入指定的ID就可以修改對應用戶的個人信息。

// @Tags SysUser// @Summary 設置用戶信息// @Security ApiKeyAuth// @accept application/json// @Produce application/json// @Param data body system.SysUser true "ID, 用戶名, 昵稱, 頭像鏈接"http:// @Success 200 {string} string "{"success":true,"data":{},"msg":"設置成功"}"http:// @Router /user/setUserInfo [put]func (b *BaseApi) SetUserInfo(c *gin.Context) {  var user system.SysUser  _ = c.ShouldBindJSON(&user)  if err := utils.Verify(user, utils.IdVerify); err != nil {    response.FailWithMessage(err.Error(), c)    return  }  if err, ReqUser := userService.SetUserInfo(user); err != nil {    global.GVA_LOG.Error("設置失敗!", zap.Error(err))    response.FailWithMessage("設置失敗", c)  } else {    response.OkWithDetailed(gin.H{"userInfo": ReqUser}, "設置成功", c)  }}

0x05 測試過程

常用測試思路：

密碼重置中如果有不需要輸入原密碼就能修改密碼時，在修改密碼處抓包，修改數據包中的用戶名或用戶ID等，測試是否能修改其他用戶的密碼；

修改用戶資料時修改用戶ID，測試是否能修改其他用戶資料；

查看訂單時，遍歷訂單ID ，測試能否查看其他用戶訂單；

攻擊者越過中間校驗步驟直接進行后續操作，導致中間校驗等步驟失效，對于這樣的流程越過漏洞通常的測試思路是，首先完成正常的業務邏輯步驟，獲取每一個步驟的請求，再繞過中間步驟直接訪問最后一個或幾個的驗證請求，測試是否能成功訪問。流程越過在密碼修改、密碼重置、購買商品處出現的可能性較大，這些測試點可著重留意。

當對一個有注冊功能或是存在身份認證的站點，可以申請兩個同級的賬戶進行水平越權測試。不過最好是讓客戶提供一個管理員用戶、兩個同級賬戶，完成水平越權、垂直越權測試。就可以替換賬號的token進行測試。分析每個參數的功能，盡可能的多去嘗試修改，比如，任意加減參數值或將false修改為true、success，看看會有什么變化，執行某一操作的時候刪除cookie、token后有什么變化。

測試案例1

在頁面上使用普通賬戶操作請求。登錄用戶A時，正常更改或者查看用戶A信息，抓取數據包，將傳參ID或其他參數修改為其他用戶，如果能成功查看或修改了同權限的其他用戶信息，就屬于水平越權，如果影響到的是高權限用戶，就是垂直越權。測試案例1通過身份信息偽造進行水平越權。

test登錄成功后的請求包中card_id與響應包中card_id、頁面中“會員號：20128880322”一致，響應包返回test用戶的用戶名以及md5加密后的密碼。猜測card_id為身份控制參數，嘗試是否可以通過修改card_id獲取其他用戶的用戶名、密碼。

回到登錄頁面，頁面底部有其他用戶賬號頭像，響應包中列出這些頭像的文件名，按照順序馬春生的應該是第一個20128880316，這個編號與test用戶card_id相似，猜測是否就是馬春生的card_id。

將test登錄成功的請求包中的card_id值更改為20128880316，得到用戶名m233241和md5加密的密碼，將密碼解密后成功登錄馬春生賬號。

還有種情況是身份控制參數直接出現在URL中，對此就可直接遍歷URL中的參數值獲取其他用戶的信息。

修復：

身份信息必須進行加密傳輸，要采取標準的加密方式進行加密，并保存好密碼，盡量不要使用base64編碼等非強加密算法，即使使用base64傳輸，也需要加入臟數據進行混淆，增加破解難度。

測試案例2

登錄lili賬號可以查看到lili的個人信息，URL中出現username參數username=lili，猜測可能是通過此參數控制身份信息。

直接修改URL中username的值，改為lucy，成功查看到lucy個人信息，這是一個水平越權漏洞。

出現此漏洞的原因是，源碼中沒有判斷用戶身份，需要添加一段判斷get請求是否來自lili（也就是當前登錄的用戶）的代碼，拒絕越權的嘗試。

測試案例3

使用管理員登錄，管理員有創建用戶的權限，添加用戶，抓取添加用戶的數據包

發送至Repeater模塊，Go一下，順利創建新用戶。

退出admin用戶，再次提交添加用戶POST請求。再次登錄admin用戶，發現并沒有新用戶被創建。

登錄用戶pikachu，只有查看權限。

復制pikachu用戶的Cookie，與之前admin用戶登錄時添加用戶的POST請求中的cookie進行替換，更改username的值，再次發送數據包，試試能否創建用戶。再刷新網頁，能看到test123123已經添加成功。說明后臺沒有對當前登錄賬號的操作進行正確的權限認證，存在垂直越權漏洞。

修復：

在每個步驟的session都應該添加標識位，并將session與用戶的身份進行強綁定，并在新步驟顯示之前必須要檢測之前每一步的session標志位。

關于密碼修改的地方還可以使用一次性填寫所有的校驗信息，例如原始密碼、新密碼等信息后再提交/重置密碼請求。

0x06 檢測工具

Authz插件：

下載地址：https://github.com/portswigger/authz使用方法：https://gh0st.cn/archives/2019-06-27/1?hmsr=toutiao.io&utm_campaign=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

平時做測試發現越權漏洞大多是基于修改ID的方式：將A用戶的ID改成B的ID，然后進行請求查看是否可以越權獲取到信息，或當ID的規律已知情況下基于Burp Intruder模塊直接去遍歷ID。

而基于Authz的檢測是不一樣的，它是將用戶認證的HTTP請求頭進行修改（Cookie之類的），然后通過響應長度、響應狀態碼判斷是否存在越權；

從本質上來講沒有任何區別，只是換了一個角度，但這樣的好處是一定程度上的減少了測試的時間（例如：一個商城的業務系統，你有A、B賬戶，A賬戶買了個商品獲得一個訂單信息請求，當你想測試是否能越權獲取B賬戶訂單時就需要使用B賬戶去再購買，然后判斷測試。）

優點：使用簡單、省時省力；

缺點：只適用于檢測越權讀取類的操作，刪除編輯類操作還需要人工判斷。

secscan-authcheck

下載地址：https://github.com/ztosec/secscan-authcheck

secscan-authcheck工具比較強大，安裝也比較麻煩，需要搭建自己的服務器，將工具安裝在服務器上，然后需要在瀏覽器安裝插件，將瀏覽器訪問流量導入自己的服務器上，使用該工具檢測是否有越權漏洞。

0x07 風險分析

用戶可以操作比自己高權限用戶操作范圍的數據（如管理員賬號），具體危害與對應業務的重要性相關。

不同的用戶應該擁有不同的權限去做增刪改查等操作，惡意攻擊者可利用該漏洞去越權查看、修改其他用戶的敏感信息，對賬戶安全造成威脅

0x08 加固建議

越權漏洞的本質就是訪問到當前用戶本不該訪問的頁面、執行不該執行的操作，所以對用戶的權限驗證尤為重要。

1. 完善安全架構、用戶權限體系。知道哪些數據對應哪些用戶，哪些數據不應該由哪些用戶操作；

2. 鑒權，服務端對請求的數據和當前用戶身份做校驗；

3. 不要直接使用對象的實名或關鍵字，例如訂單ID使用隨機數；

4. 對于用戶訪問角色的權限進行嚴格的檢查及限制，前后端同時對用戶輸入信息進行校驗，雙重驗證機制；

5. 在一些操作時可以使用session對用戶的身份進行判斷和控制；

6. 調用功能前驗證用戶是否有權限調用相關功能；

7. 執行關鍵操作前必須驗證用戶身份，驗證用戶是否具備操作數據的權限；

8. 直接引用對象的加密資源ID，防止攻擊者枚舉ID，敏感數據特殊化處理；

9. 永遠不要相信來自用戶的輸入，對于可控參數進行嚴格的檢查與過濾；

訂單號此類參數，以隨機方式生成，再進行算法加密，或者請求的數據包額外附帶一個參數，比如token，從而防止重放和遍歷訂單號這類攻擊；
前后端同時對用戶輸入信息進行校驗，雙重驗證機制；
做過濾器，對權限進行全局校驗（每次調用某個接口時，可先對權限進行校驗）第一步清洗URL地址，并提取API接口名稱，第二步從session中提取當前登錄用戶的userid，第三步，提取當前用戶的角色ID，第四步，判斷當前用戶對應的角色是否有權限訪問當前API接口（檢查垂直越權），最后判斷當前登錄用戶是否對目標對象有操作權限（檢查水平越權）。

參考http://www.360doc.com/content/22/0309/08/77981587_1020713343.shtmlhttps://www.csdn.net/tags/MtTaEgysNDk1MTg1LWJsb2cO0O0O.htmlhttps://mp.weixin.qq.com/s/vwF7aTvk-U-SnJqO3f80gA

越權訪問測試