本文記錄了一次水平越權的全過程，大致發(fā)生了如下：

修改post參數(shù)，導致越權查看和刪除；

修改路徑（REST風格參數(shù)），導致越權修改；

修改cookie字段，繞過登錄實現(xiàn)未授權訪問；

越權編輯植入xssPayload，獲取完整cookie。好了，開始虛構。

0x01 越權查看和刪除

注冊登錄進入個人中心，一通胡亂測試，發(fā)現(xiàn)可通過修改參數(shù)來越權查看或修改任意用戶資料。這里就拿教育經(jīng)歷做演示吧。

1、先創(chuàng)建，再修改。

2、抓包攔截重放，通過infoId去引用對象，返回用戶信息，并進入編輯狀態(tài)。

3、請求包中通過infoId參數(shù)引用對象，sql注入無果，嘗試修改infoId值，引用對象成功，返回其他用戶信息。刪除時修改post參數(shù)值同樣可越權刪除任意用戶信息。

4、繼續(xù)編輯自己的自我評價，點擊保存。發(fā)現(xiàn)前面infoId的值跑到路徑中去了，也嘗試修改一下（注意這里涉及修改了，就不要隨意修改了，可以嘗試修改另外的測試賬號的內(nèi)容）。

5、返回修改成功（去目標賬號中刷新，發(fā)現(xiàn)資料確實被修改了）。

6、為什么路徑也能作為參數(shù)測試點呢，因為這里使用的是REST風格參數(shù)。

0x02 繞過登錄未授權訪問

前面一頓操作，一直沒能獲取到手機號郵箱等敏感信息，結果發(fā)現(xiàn)這些基本信息的編輯使用的不是同一套流程，為了能扒出來，就有了下文。

1、下面是預覽資料的請求，沒看到get/post參數(shù)啊，自然不存在“不安全的直接對象引用”這類越權漏洞。

很明顯是通過cookie鑒別的，又這么多字段，一般這種我都不考慮越權（頭不夠鐵），不過乍一看cookie中字段值貌似都為base64編碼。竟然都是base64編碼的，這！

2、控制變量法，逐個字段刪除，找出有效的字段（刪除某個字段，頁面無變化說明該字段是無效字段，相信大家都知道這個技巧）。

一番刪除操作，只留下了 career_id 這個字段。重放返回該個人資料，修改刪除該字段便異常，說明服務端僅校驗該字段。

僅校驗一個字段，看似使用是簡單的base64編碼，不錯不錯！

3、解碼看看，5160397估計就是該用戶id了。

4、通過Burpsuite的Intruder模塊遍歷career_id字段，抓個別的id看看。

5、使用該id，成功越權訪問到該用戶的個人簡歷信息。

6、接下來，復制該cookie替換掉自己瀏覽器中的cookie，成功繞過登錄，未授權訪問其他用戶個人中心，且可進行資料編輯刪除等操作。

0x03 利用“self-xss“獲取更多權限

正經(jīng)的越權到上面差不多就結束了，下面就是利用的“歪門邪道”了。

1、進一步摸索發(fā)現(xiàn)，其實僅僅是個人中心的訪問憑證是只校驗 career_id 這一個字段，其他頁面還校驗了更多的cookie字段，只有校驗通過才可訪問更多頁面查看崗位信息、投遞簡歷等操作。

2、其實吧，編輯資料這里還存在個存儲型XSS。簡歷編輯頁的存儲型xss，基本是個self-xss無疑了，一般誰能訪問到我的簡歷編輯頁。

3、竟然都能越權編輯他人簡歷了，那我們是不是可以在編輯別人的簡歷的時候向其中植入xssPayload，一套“越權 + self_xss”組合拳。

另外，不難從前面的請求包中看出，這些資料編輯操作，一定是存在CSRF漏洞的。那么，又一套“CSRF + self\_xss”組合拳。

當然，CSRF肯定不如我們越權編輯穩(wěn)當。

接下來就等目標訪問了。..。..

這里就簡要分析下思路，就不做演示了。

0x04 總結

總結一下測試水平越權漏洞的基本思路：

控制變量法刪除參數(shù)或cookie字段，找到有效參數(shù)或cookie字段；

盡可能的對參數(shù)或cookie字段去模糊化，再進一步測試；

修改參數(shù)值或cookie字段，對增刪改查等操作進行越權測試；

越權結合其他漏洞提升危害等級。越權漏洞也可以結合Authz這類burp插件來測試，不過一般都局限于查看操作的越權。