一文理解訪問控制漏洞和提權
簡介
什么是訪問控制
拆分成2塊，訪問和控制。訪問就是誰訪問，訪問什么東西；控制就是決定這個人是否能夠訪問這個東西。專業術語就是：訪問者向受保護資源進行訪問操作的控制管理。該控制管理保證被授權者可訪問受保護資源，未被授權者不能訪問受保護資源。
是誰訪問，訪問什么東西，是否能夠訪問——>訪問控制，因此也可以理解訪問控制依賴于身份認證和會話管理
- 身份認證：確定訪問者的真正身份
- 會話管理：確定用戶發出的一系列 HTTP 請求(也就是用戶所要訪問的東西)
- 訪問控制：確定用戶是否能夠執行他們的這種操作(也就是用戶是否能夠訪問他們所想要的內容)
訪問控制的分類
- 垂直訪問控制：控制不同權限等級的用戶能夠訪問應用程序不同的功能。例如：管理員可能能夠修改或刪除任何用戶的帳戶，而普通用戶無權訪問這些操作。
- 水平訪問控制：控制用戶只能訪問自己所被允許的資源而無法訪問相同權限等級下其他用戶的資源。例如：銀行應用程序將允許用戶查看交易并從他們自己的賬戶進行支付，但不允許任何其他用戶的賬戶。
- 上下文相關的訪問控制：根據應用程序的狀態或用戶與應用程序的交互來限制對功能和資源的訪問，可防止用戶以錯誤的順序執行操作。例如，零售網站可能會阻止用戶在付款后修改其購物車的內容。
訪問控制漏洞的影響
訪問控制漏洞就意味著訪問控制有著會被破壞的可能，那用戶就可以訪問到一些不被允許的內容以及執行不在他們權限之內的操作。
簡單來說，訪問控制漏洞可能會導致權限提升
靶場
未受保護的功能導致縱向提權
對一些敏感功能沒有進行保護，敏感功能的 URL 在其他位置被公開或者能夠對其進行暴力破解，敏感功能頁面能夠通過 URL 被任何人所訪問。
- 易發現、簡單的 URL
通過訪問 /robots.txt 發現管理員頁面的存在
- 通過 URL 訪問管理員界面
- JS泄露 URL
雖然敏感功能界面的 URL 進行了一定的隱藏處理，例如加上一些雜亂的字符
這會讓我們難以猜測到它，但是可能這些 URL 會在 JavaScript 中暴露出來。
進入靶場，右鍵訪問源代碼或者通過 bp 查看 response
之后通過 URL 訪問便可
基于參數的控制訪問
服務器在用戶登錄時確定用戶身份后，將表明用戶身份的信息儲存在一些用戶可以控制的地方，例如：隱藏字段、cookie 或預設的查詢字符串參數。都說是用戶可控制的地方了，那就意味著我們可以對這些信息進行隨意的更改，那么就可以進行權限提升了。
- 使用 cookie 鑒別用戶身份
該靶場使用 cookie 中的值來確定是否為管理員的身份
- 可以使用 bp 的修改請求頭部功能，bp會將每一個請求中的 cookie 的 false 改成 true
- 或者在操作界面對每個請求進行攔截，將 false 改成 true
- 利用用戶配置屬性判斷用戶身份
在靶場中的更改郵箱處，查看服務器回顯，利用 roleid 鑒別用戶身份 - 在 JSON 中添加該屬性，服務器回顯為 2
平臺的錯誤配置導致控制訪問失效
- 通過 URL 繞過訪問控制
服務器辨別用戶所請求的內容依靠的是 http 請求的請求行中的 URL，而 http 請求的請求頭中有個X-Original-URL 或 X-Rewrite-URL屬性能夠覆蓋掉請求行中 URL 的路徑。
當 get 請求的請求行中的 URL 為空時，我們所請求的 URL 就會被 X-Original-URL 的值所替代
- 圖中的屬性值僅用于測試服務器是否支持 X-Original-URL 標頭，如果服務器不支持那通過這個方法嘗試繞過服務器的限制就不太行了。
返回響應是 “not found” 說明服務器嘗試返回 URL 為 /abdb 的頁面，只是該頁面不存在，那也就說明這個服務器是支持該標頭的。
嘗試繞過服務器限制，訪問 /admin 界面成功 - 通過 URL 傳參刪除目標用戶
- 通過請求方式繞過訪問控制
當服務器對于用戶所請求的界面進行限制時可能出現紕漏，僅僅對某一種請求方式進行了限制，因此我們可以使用其他請求方式對控制訪問進行繞過。
使用 administrator 賬戶熟悉提升用戶權限所需的 URL 以及請求包體中的參數 - 當我們使用 wiener 身份進行訪問時會放回如下界面，服務器告訴我們未授權
- 對請求方式進行修改，并對自己的賬戶進行權限提升
- 使用 get 方式成功繞過服務器限制~
橫向提權
橫向提權和水平訪問控制掛鉤，當水平訪問控制機制得到破壞時就會導致橫向提權，簡單來說就是你能夠訪問和你權限同級別的其他用戶的賬戶。例如：如果一個員工應該只能訪問自己的就業和工資記錄，但實際上也可以訪問其他員工的記錄，那么這就是橫向權限。
- 請求參數決定所訪問的賬戶
服務器依靠 URL 中的參數判斷所請求的賬戶界面 - 那么對參數進行修改便是
- 通過 GUID 識別用戶
服務器使用 GUID 來標識用戶，GUID 就是全局唯一標識符，我們無法對一個用戶的 GUID 進行猜測或者預測，但是系統可能將 GUID 在某些地方泄露，例如：用戶消息或評論處。
觀察所給賬戶的 URL，發現使用一堆亂辨別用戶
- 發現在 blog 中系統暴露了用戶的 GUID
- 獲取目標用戶 ID 并修改 URL 參數
- 頁面重定向時的數據泄露
發現賬戶依舊使用 URL 中的參數來確定所請求的用戶
- 嘗試修改 id 的值，發現直接被重定向至 /login 界面
觀察 bp HTTP history ，發現在重定向過程中有數據泄露
橫向提權到縱向提權
在某些情況下，攻擊者可以通過利用橫向提權進行縱向提權。例如：攻擊者通過橫向提權獲得管理員的密碼并破壞了他的賬戶，并使自己獲得管理訪問權限，那么攻擊者的執行權限得到了擴大從而縱向提權。
- 密碼泄露造成縱向提權
首先該靶場存在橫向提權漏洞，所請求的賬戶頁面由 URL 中的參數所決定
- 而在該頁面中存在著密碼泄露
- 修改 URL 參數，并查 administrator 賬戶密碼
- 不安全的直接對象引用(IDOR)
什么是 IDOR：是數字安全中的一種訪問控制 漏洞。[1]
當Web 應用程序或應用程序編程接口使用標識符直接訪問內部數據庫中的對象但不檢查訪問控制或身份驗證時，就會發生這種情況。例如，如果發送到網站的請求URL直接使用易于枚舉的唯一標識符（例如http://foo.com/doc/1234），則可能會提供對所有記錄的意外訪問的利用。
我也不太懂這題為什么和 IDOR 搭邊，應該是對 /download-transcript/1.txt 進行訪問時沒有進行身份認證吧。
view transcript 發現序號從2開始遞增，修改 get 請求中的參數，獲得密碼。
多步驟流程中的訪問控制
一些網站通過一系列步驟實現重要功能，但在多步驟的情況下，一些網站可能只對其中的一些步驟進行了嚴格訪問控制而忽略了其他。
例如：
更新用戶詳細信息的管理功能可能涉及以下步驟：
- 加載包含特定用戶詳細信息的表單。
- 提交更改。
- 查看更改并確認。
假設訪問控制正確應用于第一步和第二步，但沒有應用于第三步。實際上，網站假設用戶只有在已經完成了正確控制的第一步后才能到達第三步。在這里，攻擊者可以通過跳過前兩個步驟并直接提交帶有所需參數的第三步請求來獲得對該功能的未經授權的訪問。
- 多步流程中控制訪問缺失
觀察 administrator 的升級權限的過程，我們可以發現有如下步驟：點擊 upgrade——>詢問是否確定進行 upgrade——>提交最終結果
- 而漏洞也就產生于最后結果的提交，服務器對于這個步驟缺少了訪問控制，那么思路也就很明顯了：
利用 wiener 賬戶偽造一個最終提交結果即可
基于 Referer 的訪問控制
什么是 Referer：HTTP 請求頭中的一個信息字段，表示當前頁面是通過此來源頁面里的鏈接進入的，用于識別訪問來源。通俗一點講就是，告訴服務器是哪個網頁指引你過來的。
某些應用程序可能對于主管頁面有良好的訪問控制機制，但對于一些子頁面有訪問控制的缺失，例如對于子頁面的請求中只要包含有正確的 referer 那這個請求就可以被允許。在這種情況下，我們可以對 referer 字段進行偽造并獲得訪問。
- 基于 Referer 的控制訪問
在更改權限的功能中，網頁使用 get 請求來向服務器發送更改權限的信息
- 其中的 referer 表明是從 /admin 頁面發起的這個請求，那也就是說服務器依靠這個 referer 認為你是有更改權限權利的管理員。
對 wiener 賬戶的 get 請求進行偽造并發包即可
基于位置的控制訪問
一些網站根據用戶的地理為位置對資源實施訪問控制。但是這些訪問控制通?？梢酝ㄟ^使用網絡代理、VPN 或操控客戶端地理定位機制來繞過。
如何防止訪問控制漏洞
訪問控制漏洞通?？梢酝ㄟ^采取深度防御方法并應用以下原則來預防：
- 永遠不要僅僅依靠混淆來進行訪問控制
- 對于非公開的資源默認為拒絕訪問
- 盡可能使用的單一的應用程序范圍的機制來實施訪問控制
- 在開發時，強制聲明每個資源允許的訪問控制權限，并默認拒絕訪問
- 徹底審核和測試訪問控制機制，并確保它們按所設計的工作
