談談水平許可權繞過

前言

隨著計算機技術的發展，各種各樣的網路信息系統也如雨後春筍般地出現，這些信息系統無疑給人們的工作學習和生活帶來極大的方便，而作為計算機網路信息系統的開發者，確保這些信息系統的安全也成了工作的重點。如果是因為計算機系統導致用戶信息泄露的後果是不堪設想的。而今天這篇文章，我們就來談一談水平許可權繞過（Horizontal privilege escalation）。

什麼是水平許可權繞過

水平許可權繞過通常是指用戶對某些計算機資源進行訪問或者寫入的時，由於計算機程序缺乏對用戶身份的校驗，而導致了其他用戶的資源遭到讀寫的情況。而水平許可權繞過型攻擊，則是指黑客通過上述計算機系統缺陷，對計算機系統實施系統數據的未授權讀取寫入操作。

用比較通俗簡單的例子說，在某電商平台購物，購物後返回訂單號查詢頁面，其url為http://demo.com/viewOrder?id=201803302515，如果對該鏈接實施修改，把「201803302515」部分修改為其他值，如201803302555後，能夠獲取到其他用戶的訂單信息，那麼這個過程就是一個水平許可權繞過的攻擊了。簡單地說，通過修改請求參數，若能夠使用戶能夠實現一些未授權的訪問操作（如看到不該看的東西，寫了不該寫的東西，讓計算機做了不該做的東西等等），就證明該系統存在水平許可權繞過的漏洞了。

大家在看了上面的定義以及那個例子以後，可能會覺得這一過程會比較簡單，幾乎有腦子的人都不太可能會犯這種錯誤，的確上述的情景在真實情況下比較少見，不過水平許可權繞過的漏洞在很多系統中卻都可以找到它的身影，因此我們也簡單地說一下幾個例子，通過這些例子的話，相信大家能夠對水平許可權攻擊有更深的了解。

大學通常都有校園網繳費系統，而在本案例中的網路繳費系統，用戶若需要繳費，則需要選擇續費時長，系統會自動計算出所需繳納費用，用戶選擇支付方式後，系統生成訂單跳轉去學校結算系統進行結算。

而問題則出現在系統計算費用的部分。

對網站前端進行分析，發現生成訂單實際上由一個Javascript函數控制，而最終提交訂單的這是通過以下代碼實現：

通過對月份數和金額進行修改，嘗試性提交訂單，發現能夠提交成功，能夠以任意金額實現對任意時間長度續費（五毛錢錢續費到3123年都可以）。

不難看出該系統後台對系統前端的數據並沒有任何的校驗機制，直接處理了前端的請求，因此導致了用戶可以用任意金額續費任意時長的網路服務。

某課堂互動平台是一個廣受大學教師歡迎的一個在線課堂交互平台，用於給學生簽到，討論等等的功能。

漏洞的發現源於有用戶反映該課堂互動平台的討論區匿名功能的非匿名性。非匿名性體現的問題是其留言項將用戶全部信息進行了輸出。

針對該系統前端代碼進行進一步的分析發現，其系統或許存在著更嚴重的漏洞。遂進行進一步的測試。

發現該系統存在若干信息讀取寫入的API，這些API要求提交參數有被操作的學生、教師的ID以及課堂、課程的ID，於是嘗試製作相關請求獲取學生列表，發現能夠成功獲取。進一步測試系統的未授權寫入操作，發現寫入操作亦可以正常進行，筆者成功將一新註冊用戶添加為某一課堂的教師，並以教師身份成功進行任意操作。可見該系統對用戶的輸入完全沒有校驗，而只對token的有效性進行校驗，而token的有效性並沒有對其的可讀可寫許可權進行嚴格的控制，從而導致漏洞的發生。

該數字出版物網站提供雜誌的在線預覽功能，允許未訂閱用戶瀏覽若干頁內容，然而在對前端源碼進行分析後發現，預覽功能允許用戶閱讀的數量是通過若干參數控制的，在開發者模式中對相關參數進行重新設置，未訂閱用戶即可無限閱讀全部內容。

支付寶二維碼紅包領取漏洞

支付寶的掃碼領紅包也出現過類似的漏洞，新聞報道稱通過某頁面輸入不同的手機號，即可實現偽造領紅包的請求。筆者猜測，新聞所述的「某個頁面」實際上應該就是用戶掃描支付寶紅包二維碼後的著陸頁面，該著陸頁的請求參數中包含用戶的手機號作為唯一識別參數。該漏洞被人發現及利用，不過利用者也因此惹上了麻煩。

可見，各類型的水平許可權繞過的漏洞在互聯網中廣泛存在，而許可權繞過所會造成的後果也是顯而易見的。而漏洞的危險程度也隨著系統性質和規模的不同而不同，對於像上述的網路繳費系統、交易系統，這些涉及到商品交易的網站，許可權繞過會導致錯誤訂單的生成，而錯誤訂單一旦交易成功將會對網站主辦方造成嚴重的損失。對於上述的課堂互動平台，雖然這些平台相對於前者並不是十分的重要，但是這些平台往往會有比較大的用戶量，在如此大的用戶量下，許可權繞過能讓未授權者獲得大量用戶信息和資料，這樣一來極有可能會導致大規模的用戶信息泄露。而至於一些電子書閱讀網站，預覽控制項的設計缺陷讓用戶能夠免費閱讀電子書預覽以外的付費內容，這也不是主辦方想要的結果，不過相對於其他的case而言，其危險性及後果並不是很高嚴重。

所有的漏洞說到底都是人為的設計失誤導致的，要預防這類型的漏洞，應做到的是在系統設計最初就應當對整個系統的用戶角色、許可權分配等做好明確的定義，並在開發過程中嚴格落實好許可權的校驗工作。業務邏輯應當放在後端完成，任何的校驗不應當只依靠於前端。如果系統設計時未曾考慮好整體的架構如何，設計和實際開發時也沒有對安全性進行任何的考慮時，水平許可權繞過此類的漏洞就極可能會發生。

最穩妥的是進行二次校驗，前端對用戶的輸入數據進行基本的合法性校驗，這一校驗主要作用是在用戶提交請求前對非法操作進行即時的提醒。而伺服器端著進行最終的校驗操作，對於非法的請求則予以忽略或提示相關的報錯信息。

其實上面講的這些避免漏洞的措施，幾乎都是老生常談了，但是這些漏洞卻屢屢出現，原因又是什麼呢？知乎一個問題「黑客能夠厲害到什麼程度」裡面與不少人都說自己曾經「黑」過什麼系統、網站的經歷，但是實際上，很多時候這並不是黑客或者白帽子能夠厲害到什麼程度，而是這些計算機信息系統的漏洞能夠嚴重到什麼程度、系統管理員的安全意識弱到什麼程度。黑客和白帽子尋找漏洞大多是是依靠工具來進行掃描的，對於有可疑的站點再進行人工的滲透測試，亦有不少漏洞是在無意中發現的，這本身並不會有非常「厲害」的技術在裡面。再者，有很多最終導致嚴重後果的漏洞，往往都是一些顯而易見的漏洞導致的。這些漏洞的「製造者」，也就是這些系統的開發者，往往都是在態度上存在著很大的問題，不把安全當回事，他們總是想著能讓車子跑起來就行，卻忽視了車子的安全性。更有甚者把委託開發項目的代碼放在github上面，只是為了能夠比較方便地存取，自己單位相關平台的APISecret被「開源」了都不知道。

與其說漏洞多可怕，還不如說把信息安全當兒戲多可怕。

出於安全性等考慮，本文對涉及的漏洞的相關細節進行淡化，僅作案例討論，不針對任何組織。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！