Web安全訪問控制及權限提升漏洞

一、什麼是訪問控制？

簡單的來說就是應用程序首先會判斷用戶的身份（賬號密碼登錄），隨後確認後續請求是否由該用戶發出（會話管理），然後判斷是否允許用戶執行“所請求的操作”或訪問“所請求的資源（訪問控制）”

1、從用戶角度訪問控制模型分爲以下類型：

• 垂直訪問控制：控制不同權限等級的用戶訪問應用程序不同的功能；如“管理員”可以修改/刪除賬號，而普通賬號無法操作。
• 水平訪問控制：控制用戶只能訪問自己的資源，而不能訪問其他用戶相同類型的資源；如“銀行程序用戶只能從自己的賬號進行付款，而不能查看其他用戶的賬戶”。
• 上下文相關的訪問控制（多步驟）：防止用戶以錯誤的順序執行操作；如“零售網址阻止用戶付款後，修改訂單信息”。

2、出現訪問控制漏洞的原因：

• 理論上應用程序需要對每一個請求，以及特定用在特定時刻的每一項操作，都需要進行訪問控制檢查，但是由於該策略是人爲設定，所以常常出現安全問題。
  

二、訪問控制漏洞

應用程序允許攻擊者執行某種攻擊者沒有執行權限的操作，就會出現訪問控制漏洞。
三種訪問控制模型分別對應着

• 垂直權限提升
• 水平權限提升
• 多步驟訪問控制

並且這些漏洞之間沒有明確界限，按照漏洞的表現形式和檢測方法差異會分爲很多不同的類型：

• 未受保護的功能
• 基於標識符的訪問控制漏洞
• 基於多步驟的訪問控制漏洞
• IDOR
• 不安全的訪問控制機制
• 訪問控制繞過漏洞

三、漏洞實例

1、未受保護的功能：
應用程序對敏感功能沒有任何訪問控制，而是依賴URL的隱蔽性和不可猜測性進行訪問控制，但是功能鏈接可能在其他公開位置，如robots.txt或者url或者js，html或者css中
造成垂直權限提升漏洞：
實例1：通過robots.txt文件找到後臺鏈接

實例2：網站通過對管理員頁面進行了複雜命名，無法通過猜測和爆破發現，但是在響應消息中發現該URL。

2、基於標識符(參數)的訪問控制
某些應用程序可能利用參數的不可預測性，例如將用戶身份標識uid設置爲無法猜測的隨機值；但是該uid可能會在應用程序中公開，如“評論”、“用戶消息”等位置。

造成水平權限提升漏洞

實例1：更換用戶身份標識的參數
用戶通過以下URL訪問賬戶頁面https://insecure-website.com/myaccount?id=123、https://ac161fa11e6ee89a80855e0a00b200c2.web-security-academy.net/my-account?id=carlos
如果用戶通過將id變更，可能會訪問到其他另一個用戶的賬戶頁面
首先抓取用戶查詢key的請求

在網站的響應頁面中找到了其他用戶的id

替換id即可越權查看該用戶的KEY

造成垂直權限提升漏洞

應用程序在登錄時確定用戶的訪問權限或角色，然後將其存儲在用戶可控制的位置（如：隱藏字段、cookie或預設查詢字符串、響應內容），應用程序根據提交的值做出訪問控制。攻擊者能夠修改標識訪問權限或角色的參數進行權限提升。

實例1：攻擊者可以修改url中的參數（其標識用戶或其權限）。
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1

實例2：攻擊者可以修改cookie中的參數（其標識用戶或其權限）。
直接請求管理頁面失敗

嘗試將cookie中的參數進行變更

成功繞過訪問控制

實例3：攻擊者分析響應可發現權限配置參數（其標識用戶或其權限），並將其添加到修改請求中。
查看響應中包含用戶的其他信息。

嘗試提交該請求，失敗

嘗試多個參數同時提交，成功越權

造成水平-垂直權限提升

實例1：修改標識用戶身份的參數爲管理員
攻擊者可以使水平權限提升漏洞轉變爲垂直權限提升漏洞，如“https://insecure-website.com/myaccount?id=456“變更id參數，能夠訪問其他用戶的賬戶頁面，如果通過將id變更爲管理員，獲取管理員賬戶的訪問權限。

3、基於多步驟的訪問控制漏洞

實例1:使用高權限賬戶抓取多步驟的全過程

使用低權限用戶訪問這２個請求，發現第二個階段可以越權訪問。

4、不安全的直接對象引用IDOR
當應用程序使用用戶提交的數據直接訪問對象時，就可能出現IDOR漏洞。攻擊者通過變更引用的對象進行攻擊。

直接引用數據庫對象的IDOR漏洞

實例1：
如果網站從數據庫中查詢客戶信息的URL如下：https://insecure-website.com/customer_account?customer_number=13235
攻擊者可以變更customer_number的值，繞過訪問控制查看其他客戶信息，造成權限提升漏洞。

直接引用靜態文件的IDOR漏洞
敏感信息位於服務器端的靜態資源中，容易出現IDOR漏洞。
實例1:攻擊者通過修改靜態文件ID，越權獲取其他信息

直接引用方法的IDOR漏洞
應用程序的API的URL和參數被泄露，或方法名可猜測，可能出現直接引用方法的IDOR漏洞。

實例1:
系統某些API的URL：http://wahh-app.com/public/securityCheck/getCurrentUserRoles
如果系統除對getCurrentUserRoles方法外，其他方法沒有訪問控制，就會出現安全風險。如（getAllUserRoles、getAllRoles和getAllusers等）。

5、不安全的訪問控制機制
基於referfer的訪問控制漏洞，有些應用程序基於referer（標識http請求發起的網頁url）進行訪問控制，由於該參數客戶端可控制就會出現漏洞。

實例1：
網站管理後臺"/admin"進行了嚴格的訪問控制，但是管理後臺的子頁面如“/admin/deleteuser”僅校驗了referer是否包含"/admin"路徑，就會出現漏洞。

基於地理位置的訪問控制漏洞
有些網站對用戶的地址位置進行訪問控制。攻擊者可以通過VPN、web代理繞過限制。

訪問控制阻斷機制錯誤漏洞
訪問控制阻斷所產生的重定向頁面，可能就包含越權訪問的信息。

實例1:越權阻斷響應中包含敏感信息
以下請求會被JS重定向，但是源代碼中還是泄露了越權信息。
6、訪問控制繞過漏洞
基於HTTP方法和覆蓋路徑的繞過方式

應用程序對用戶角色訪問的url和http方法實施訪問控制，如：DENY:POST, /admin/deleteUser,managers，即拒絕managers角色用戶使用post方法訪問/admin/deleteUser路徑。
一些web框架支持非標準HTTP頭，使用X-Original-URL和X-Rewrite-URL可覆蓋原始中的URL能夠繞過前端控件的訪問控制。
一些網站支持其他http請求方法，因而攻擊者能夠繞過前端控件的訪問控制。

實例1：攻擊者使用X-Original-URL覆蓋url中的路徑。
直接請求發現，被攔截

使用X-Original-URL覆蓋url的路徑後成功越權

實例2:攻擊者使用修改HTTP方法
使用administrator用戶操作，並抓取修改wiener用戶權限的請求

使用wiener用戶發起請求失敗
修改HTTP請求方法，成功繞過