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