Web安全之攻擊訪問控制

從邏輯上講，應用程序的核心安全機制——訪問控制建立在驗證和會話管理之上，如果應用程序的訪問控制存在缺陷，攻擊者往往能夠很快的攻佔這個應用程序。訪問控制漏洞的概念其實很簡單即應用程序允許攻擊者執行或者訪問某種攻擊者不具備相應權限的功能或資源。常見的訪問控制可以分爲垂直訪問控制、水平訪問控制及多階段訪問控制（上下文相關訪問控制），與其相應的訪問控制漏洞爲也垂直越權漏洞（普通用戶可以訪問或執行只有管理員才具有權限訪問或執行的資源或功能），水平越權漏洞（某一用戶可以訪問或執行另一個用戶纔有權限訪問或執行的資源或功能）及多階段越權漏洞（某個操作可能需要多個步驟，比如銀行轉賬，攻擊者可能跳過前面步驟直接執行最後的步驟）。

常見的漏洞

有些功能根本就沒有執行訪問控制：

某些應用程序天真的認爲只要將某些敏感的資源或者功能的訪問路徑僅公佈給具有相應權限的用戶就可以保證系統的安全，這種想法太天真了，攻擊者可以通過各種途徑發現那些路徑，比如路徑爆破或者利用Google，百度等強大的搜索引擎。更甚的是那些敏感資源或者功能的路徑有可能會直接出現在HTML源碼中，由前端的JS代碼判斷用戶權限從而決定顯示與否。比如下述代碼：

var isAdmin = false;
if(isAdmin){
	adminMenu.addItem("/menus/secure/ff457/addNewProtalUser2.jsp","Create a new user");
}

除了上述情況外某些外部API的調用也是有可能不受權限訪問控制的,比如某一用戶應該僅允許訪問securityCheck接口的getCurrentUserRoles方法，如下所示：

http://wahh-app.com/public/securityCheck/getCurrentUserRoles

但是經過檢查後發現還可以訪問當前用戶不具有權限訪問的功能，比如：

http://wahh-app.com/public/securityCheck/getAllUsers

基於標識符的功能：

現實中某些應用程序還可能使用標識符來確定某一用戶的身份，這種標識符通常作爲Get，Post或者Cookie裏面的某個參數，比如：

http://wahh-app.com/home.php?userId = 1305335

這種情況下攻擊者僅需要通過遍歷標識符或者在各種日誌中收集標識符即可實現水平越權或者垂直越權。

多階段功能：

某些應用程序在實現諸如添加用戶，賬戶轉賬等需要多個階段才能完成的功能時經常會認爲用戶既然成功的到達了當前階段那麼前面階段肯定已經對用戶的權限進行了驗證，從而此階段就不會再次驗證而是直接允許此步驟的操作。這種想法如果被開發者實踐到應用程序中就會存在這樣的問題，比如攻擊者摸清了最後一個階段需要向服務器提交的各種參數那麼他就可以通過直接構造參數並像最後一個階段的處理文件提交從而避開權限驗證直接實現添加用戶或者轉賬的功能。

靜態文件：

像doc、xml、pdf等靜態文件不具有權限驗證的功能，只要用戶對其訪問就可以對這些文件進行下載。比如我們在線購買圖書的時候，有些網站在用戶完成付費後直接拋給用戶一個下載鏈接：

https://www.wahh-books.com/download/9780636628104.pdf

如果沒有付費的用戶也能夠通過這個鏈接下載圖書的話那麼就存在權限驗證漏洞

平臺配置錯誤：

一些Web應用程序依賴於Web服務器或者其所依託的平臺來進行權限控制，這些平臺在設置權限控制規則時和防火牆設置過濾規則時類似，比如他們都會基於以下條件設置相應的允許或者拒絕規則：

• HTTP請求方法(比如通過HTTP Verb Tampering可以繞過HTTP認證等)
• URL路徑
• 用戶角色

但是在進行權限控制配置時出現的一些錯誤可能會造成權限控制漏洞，比如我們想通過禁止非Admin角色的用戶向userAdd.php使用POST請求方法傳遞數據以防止非Admin角色用戶執行用戶添加功能。但是上述規則並不安全，如果後臺代碼通過$_REQUEST變量獲得參數，那麼此時攻擊者可以使用Get請求方法或者在Cookie設置參數繞過上述規則實現越權添加用戶。

訪問控制方法不可靠

有時Web應用程序所執行的訪問控制方法並不可靠，比如下面三種情況：

• Web應用程序基於參數進行訪問控制，這種情況下普通用戶只需要將自己的URL、POST數據或COOKIE中添加相應的參數即可實現權限提升。如下所示：

https://wahh-app.com/login/home.jsp?admin=true

• 基於Referer實現訪問控制，即Web應用程序會根據用戶訪問當前頁面的Referer來判斷用戶是否具有訪問權限，這樣做的假設是如果用戶通過管理界面上的添加用戶的鏈接來訪問添加用戶功能，那麼此時訪問添加用戶功能的HTTP請求中會攜帶有值爲管理界面URL的Referer頭部參數，那麼反過來如果訪問添加用戶功能的HTTP請求攜帶有值爲管理界面URL的Referer頭部參數就認爲是通過訪問管理界面的添加用戶鏈接過來的而管理界面需要會進行權限控制，爲此可以把添加用戶功能的權限控制依賴於管理界面的權限控制。然而上述假設是不成立的因爲Referer頭部參數是客戶端可控的，用戶可以隨意對其進行更改，這種情況下攻擊者只需要在訪問添加用戶功能時將Referer頭部參數修改爲管理頁面的URL就可以越權操作了。
• 基於位置的訪問控制，即應用程序會根據用戶的地理位置來限制對資源的訪問。但是Web應用程序通常根據IP地址來判斷用戶的地理位置，這種判斷地理位置的方式是不可靠的，攻擊者可以藉助代理機器來輕易繞過地理位置的限制。

常見的攻擊套路

在測試某一個應用程序的訪問控制前摸清下面幾個問題可以使我們的分析過程事半功倍：

1. 哪些資源屬於用戶特定的訪問資源
2. 應用程序用戶角色的劃分
3. 管理員角色是否與普通用戶使用的是同一個Web應用程序
4. 尋找那些可以有助於權限提升的功能和資源即攻擊點或者待分析的點
5. 尋找任何標識符

不同用戶賬戶進行測試

在進行此測試時攻擊者可以藉助Burpsuite的site map比較功能來實現自動化，步驟大致如下：

• 瀏覽器設置代理
• 使用高權限用戶瀏覽Web應用，隨後退出
• 刪除site map中登錄前和退出後的訪問記錄
• 右鍵site map中的記錄在上下中選擇Compare site map
• 分析比較結果

Compare site map的使用見此文，此功能能夠顯示不同權限的用戶對於相同資源或者功能訪問的差異，通過分析這些差異判斷是否存在權限控制漏洞。比如在訪問addUser.php頁面是高權限與低權限用戶的訪問結果相同則存在權限控制缺陷，但並不能依據兩個不同角色對同一頁面訪問時獲得了相同的響應就說這個應用程序存在安全控制漏洞，比如兩各角色訪問的都是index.php，這個頁面所有的人訪問都是相同的。相應的也不能說如果返回響應不同就不存在漏洞，比如addUser.php頁面中會顯示時間，那麼就算低權限用戶越權訪問到此頁面也可能由於訪問時間的不同與高權限用戶的訪問響應存在區別。這種方法可以發現靜態資源訪問權限控制漏洞，沒有進行權限訪問控制漏洞，基於標識符的訪問控制漏洞以及部分的訪問控制方法不可靠造成的漏洞（Referer及參數）。

測試多階段訪問

上述方法無法有效測試多階段的訪問控制，在進行多階段訪問控制是我們同樣可以藉助Burpsuite，大概測試步驟如下：

• Burpsuite開啓兩個監聽端口
• 開啓兩個瀏覽器併爲其設置代理
• 其中一個瀏覽器以高權限登錄Web應用並訪問多階段功能
• 切換到另一瀏覽器以低權限登錄
• 在Burpsuite中尋找多階段功能的HTTP訪問序列
• 使用Burpsuite針對於上述訪問序列的請求逐個右擊並在上下文中選用request in browser->in current session將URL逐個貼到以低權限身份登錄應用程序的瀏覽器中
• 比較連個請求序列的異同

通過比較高低權限用戶在訪問多階段功能時的HTTP請求序列來尋找權限控制漏洞。在對多階段功能進行權限控制分析時不僅要觀察HTTP請求序列同時也要關注單個的HTTP請求。

通過有限訪問權限進行測試

通過有線訪問控制權限進行測試即在具有了一定的訪問權限基礎上進行上述可能存在的權限控制漏洞的分析，在低訪問權限的上下文中尋找下述信息：

• 枚舉可以直接訪問的敏感功能路徑
• 像那些管理員及普通用戶共有的頁面（比如個人主頁）添加一些參數看是否能夠越權（admin=true）
• 測試應用程序是否基於Referer進行權限控制
• 觀察HTML及JS源碼發現隱藏的功能連接
• 尋找資源訪問的標識符並進行測試

其他測試方法

測試“直接訪問方法”主要是針對於挖掘前面提到的應用程序可能會對API不進行任何的權限控制的漏洞。攻擊者可以通過觀察API所提供功命名規則推測隱藏的API方法並嘗試調用觀察是否有權限限制。
針對於今天文件可以通過遍歷或者切換爲無權限用戶對其進行訪問觀察是否有權限控制來確定是否存在權限控制漏洞。
針對於平臺配置錯誤引起的權限控制漏洞我們可以通過觀察高權限用戶下改變參數提交方法是否會影響功能的調用，如果不影響那麼有可能存在權限控制漏洞。

常見的防禦模型

在爲應用程序設計權限控制時開發者借鑑下述幾條tips：

• 每個頁面強制使用驗證邏輯代碼或者引用中央驗證代碼
• 對於靜態文件的訪問可以修改爲將文件名作爲參數傳給動態文件
• 不要相信客戶端傳遞過來的任何數據，像標識符或者一些重要參數可以存在服務器端的session中
• 對於重要的功能可以採用IP驗證比如（僅允許localhost訪問），儘管這種方法還是可以繞過，但是這最起碼加大了攻擊者的訪問難度。
• 對於重要的功能執行多因子驗證

完整的權限控制體系有以下幾種

編程控制

將權限控制矩陣保存在數據庫表中，然後通過編程的形式結合數據庫中的權限矩陣對用戶進行權限控制。權限矩陣如下圖所示：

這種權限控制方式的缺點在於權限矩陣保存在數據庫中如果應用程序存在SQL注入漏洞攻擊者有可能利用此漏洞更改其對應賬戶的權限，從而達到控制整個應用程序的效果。

自主訪問控制（DAC）

即在DAC模型中管理員（或者說資源的擁有者）可以動態的添加用戶並決定賦予其的權限或者修改現有用戶的權限，DAC模型可以細分爲以下兩種：

• 封閉型DAC
  除非管理員明確許可，否則拒絕訪問
• 開放型DAC
  除非管理員明確禁止，否則允許訪問

基於角色的訪問控制（RBAC）

這種訪問控制會設定很多命名角色，每個角色擁有各不相同的權限，每個用戶可以根據需要分配一個或者多個這樣的角色。個人感覺Tomcat的後臺權限控制就是基於角色的訪問控制模型（RBAC），其配置文件如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">

    <role rolename="manager-gui"/>
    <role rolename="manager-script"/>
    <role rolename="manager-jmx"/>
    <role rolename="manager-status"/>
    <role rolename="admin-gui"/>
    <role rolename="admin-script"/>
    <user username="tomcat" password="tomcat" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" />
    
</tomcat-users>

基於角色的訪問控制在角色分配時要額外注意如果分配的太粗糙那無法細緻的劃分權限的控制，如果角色劃分太詳細則造成用戶角色分配時過於繁瑣有時可能出現差錯。

聲明式訪問控制

應用程序使用有限的數據庫賬戶訪問數據庫，不同的用戶組或者羣體使用不同的賬戶，每個賬戶分配到執行該羣體所需操作所必需的最低權限。這種聲明是在應用程序之外聲明的，是由另一個組件賦予給應用程序的，這就極大地在應用程序被攻破的情況下保證了應用程序的安全性。聲明式的訪問控制即使僅賦予某組用戶所需的最低權限，但是通過這種最低權限這組用戶也是有可能獲得文件的讀權限，這樣有可能會造成敏感文件泄露等問題，如果這組用戶讀到了應用程序管理員用戶的密碼那麼此時應用程序還是可以被攻破。

總結

權限控制時應用程序核心安全的重要一環，就算應用程序很好的執行了用戶身份驗證及會話管理，但是如果權限控制出現問題整個應用程序的安全性還是會被大大降低。應用程序在設計訪問控制模型時要考慮周密在執行時也要嚴格把控。在進行訪問控制相關的漏洞挖掘時需要細心的瀏覽對比不同權限下應用程序頁面及相應的響應，發現HTML源碼及JS腳本中隱藏的功能連接，尋找應用程序的API調用並推測其命名規則及可能提供的功能方法，着重關注多階段功能。在權限控制漏洞的發掘過程中要善於使用Burpsuite，從而儘量實現自動化。