一、越權訪問

越權訪問(Broken Access Control，簡稱BAC)是Web應用程序中一種常見的漏洞，由于其存在范圍廣、危害大，被OWASP列為Web應用十大安全隱患的第二名。

1. 越權訪問的產(chǎn)生

比如，某個訂單系統(tǒng)，用戶可以查詢自己的訂單信息。A用戶查詢訂單時，發(fā)送的HTTP請求中包含參數(shù)“orderid=A”，訂單系統(tǒng)取得orderid后最終會查詢數(shù)據(jù)庫，查詢語句類似于“select * fromtablename where orderid = A”。B用戶查詢訂單時，發(fā)送的HTTP請求中包含參數(shù)“orderid=B”，系統(tǒng)查詢數(shù)據(jù)庫語句類似于“select * fromtablename where orderid = B”。正常情況下，每個用戶只會查詢到自己的訂單。但是，當B用戶將自己的HTTP請求參數(shù)修改為“orderid=A”，那么最終B用戶執(zhí)行的數(shù)據(jù)庫語句變成了“select * fromtablename whereorderid = A”，導致A的訂單信息被B用戶獲取到了。

一般來說，網(wǎng)站設計者會用戶的訪問進行權限校驗，確保用戶僅能訪問到屬于自己的資源，但是業(yè)務復雜到一定程度之后，諸如此類的數(shù)據(jù)如此之多，從訂單信息，到地址數(shù)據(jù)、支付信息等等，無一不需要小心處理。一旦有所疏漏，就會產(chǎn)生越權訪問漏洞。

2. 越權訪問的種類

越權訪問分為垂直越權訪問、水平越權訪問和交叉越權。

垂直越權是指不同用戶級別之間的越權，如普通用戶執(zhí)行管理員用戶的權限。水平越權是指相同級別用戶之間的越權操作。

(1) 水平越權

假設用戶A和用戶B屬于同一角色X，擁有相同的權限等級，他們能獲取自己的私有數(shù)據(jù)(數(shù)據(jù)A和數(shù)據(jù)B)，但如果系統(tǒng)只驗證了能訪問數(shù)據(jù)的角色，而沒有對數(shù)據(jù)做細分或者校驗，導致用戶A能訪問到用戶B的數(shù)據(jù)(數(shù)據(jù)B)，那么用戶A訪問數(shù)據(jù)B的這種行為就叫做水平越權訪問。

(2) 垂直越權

垂直越權又叫做權限提升攻擊。其原理是由于Web應用沒有做權限控制，或僅僅在菜單上做了權限控制，導致惡意用戶只要猜測其他管理頁面的URL，就可以訪問或控制其他角色擁有的數(shù)據(jù)或頁面，達到權限提升的目的。

3. 越權訪問的測試

本文以三員系統(tǒng)為例，首先介紹一下三員系統(tǒng)。

三員系統(tǒng)初始就有三個不同權限的管理員：系統(tǒng)管理員、安全保密管理員、安全審計員，三員之間是平級的但主體功能各不相同。此外根據(jù)不同Web系統(tǒng)的需求還會出現(xiàn)三員用戶的子用戶和普通用戶，普通用戶中可能還會分出不同權限的用戶(如：操作員、監(jiān)控員等等)。

三員系統(tǒng)為了滿足保密產(chǎn)品的安全需求導致用戶權限劃分細致且眾多，相較于普通系統(tǒng)權限判斷更加繁多也更需細致，因此權限控制難度更高，導致三員系統(tǒng)出現(xiàn)越權漏洞的概率越高

(1) 三員之間的交叉越權

登錄A管理員，執(zhí)行A管理員的功能x，抓取保存x功能包。退出A管理員，登錄B管理員，抓取B管理員的COOKIE，將x功能包中的COOKIE替換成B的COOKIE，發(fā)送x功能包。通過響應包或到x功能的Web頁面處查看請求是否成功，成功則存在越權漏洞。

以上是越權通用的測試方式，但實際測試中要注意以下幾點：

• 一般Web應用是通過COOKIE里的信息來認證用戶身份的，但并不是所用Web應用的是如此的。遇到身份認證不是COOKIE的Web應用，要替換的就是該系統(tǒng)認證身份的地方而不是COOKIE。如下圖就是COOKIE認證登錄狀態(tài)，jitabc認證用戶身份。



• 遇到有COOKIE共用(多次登錄同一或不同用戶COOKIE相同)的Web應用時，因為COOKIE不變并不需要替換COOKIE直接替換Web的當前用戶就能直接發(fā)送請求來測試。但這時候未授權漏洞和COOKIE退出不清除的問題會影響越權漏洞的驗證，要在驗證越權前先確定未授權漏洞和COOKIE退出不清除這兩個問題不存在。
• 三員之間的交叉越權最常出現(xiàn)在同一功能不同權限處。如：系統(tǒng)管理員和安全保密管理員都有用戶這個功能模塊，但僅有系統(tǒng)管理員有添加用戶的功能，僅有安全保密管理員有賦予用戶權限的功能，在程序對功能模塊進行身份驗證但對其中的子功能缺乏驗證時就會出現(xiàn)越權漏洞。

(2) 三員管理員的垂直越權

本漏洞是在用戶有某一功能的權限且增刪改查的值有限制但限制不完善的情況下，會出現(xiàn)的問題。

例：

三員管理員可以添加自己權限的子用戶。抓取系統(tǒng)管理員的用戶角色添加功能，其中存在roles=1的字段，可能是角色控制的值，修改為roleid=2繼續(xù)發(fā)送發(fā)現(xiàn)請求成功，在Web端查看該用戶已被賦予安全管理員角色，很明顯存在越權漏洞。

注意：

• 在實際測試中可能不會出現(xiàn)roleid這樣明顯的角色字眼，這時候就要認真分析和嘗試出請求中每個字段的意義，在進行測試。
• 該漏洞常出現(xiàn)在用戶添加、賦予角色等跟用戶角色相關但有限制的地方，一旦程序限制不完善就會出現(xiàn)漏洞。

(3) 三員子用戶/普通用戶的垂直越權

登錄C管理員，執(zhí)行C管理員的功能y，抓取保存y功能包。退出C管理員，登錄D三員子用戶/普通用戶，抓取D的COOKIE，將y功能包中的COOKIE替換成D的COOKIE，發(fā)送y功能包。通過響應包或到y(tǒng)功能的Web頁面處查看請求是否成功，成功則存在越權漏洞。

與1.3.1類似，不同是的利用低權限用戶的身份執(zhí)行高權限用戶獨有的功能。

(4) 三員子用戶/普通用戶的水平越權

登錄E用戶執(zhí)行E用戶的功能z，抓取z功能包將其中的用戶識別id修改為F用戶的(如E修改密碼時抓取到功能包：username=E&passwd=123,修改成username=F&passwd=123)，發(fā)送請求測試F用戶對應的功能是否被修改，成功修改則存在越權漏洞。

二、未授權訪問

未授權訪問漏洞可以理解為需要安全配置或權限認證的地址、授權頁面存在缺陷導致其他用戶可以直接訪問從而引發(fā)重要權限可被操作、數(shù)據(jù)庫或網(wǎng)站目錄等敏感信息泄露。

常見的第三方未授權訪問漏洞：

• MongoDB 未授權訪問漏洞
• Redis 未授權訪問漏洞
• Memcached 未授權訪問漏洞CVE-2013-7239
• JBOSS 未授權訪問漏洞
• VNC 未授權訪問漏洞
• Docker 未授權訪問漏洞
• ZooKeeper 未授權訪問漏洞
• Rsync 未授權訪問漏洞

以上都第三方的未授權漏洞，如果Web系統(tǒng)中有用到以上組件，就要及時更新該組件修復漏洞。Web應用本身也存在未授權漏洞，常見有以下兩類：

• 沒有作任何的用戶身份認證手段。
• 一些特定的頁面或文件未做認證。

第一類問題的測試只需要隨意抓取用戶功能，將其中的用戶認證信息(COOKIE等)清空或修改然后發(fā)送，若請求成功便存在未授權漏洞。

第二類問題測試方式與第一類問題一樣，只是特定的頁面或文件才存在。一般常見于：可文件、用戶手冊、Web應用新添加的功能頁面。

三、認證信息失效機制問題

用戶正常注銷退出后，用戶的認證信息不會立刻失效。用戶認為自己已經(jīng)退出賬號，但在服務端中保留用戶登錄狀態(tài)，依然可以用認證信息進行請求。因此在要求單次登錄有效的應用系統(tǒng)中，用戶正常退出或注銷應將服務端認證信息進行注銷。

四、結語

在上述安全問題測試方法的前提是獲取到其他用戶認證信息，而實際應用場景中需要獲取其他管理員認證信息雖然很困難，但在現(xiàn)今層出不窮的網(wǎng)絡攻擊手段下，我們不得不關注這些安全問題的本身。造成“三員”中越權問題的主要原因在于對于身份認證不嚴格，角色和功能綁定存在遺漏，因此在企業(yè)重要的應用系統(tǒng)中建議在服務端進行用戶和角色的一對一驗證，角色和功能的一對一驗證，或者用戶和功能的一對一驗證。