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

修改post參數(shù)，導(dǎo)致越權(quán)查看和刪除；

修改路徑（REST風(fēng)格參數(shù)），導(dǎo)致越權(quán)修改；

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

越權(quán)編輯植入xssPayload，獲取完整cookie。好了，開始虛構(gòu)。

0x01 越權(quán)查看和刪除

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

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

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

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

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

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

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

0x02 繞過登錄未授權(quán)訪問

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

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

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

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

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

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

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

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

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

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

0x03 利用“self-xss“獲取更多權(quán)限

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

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

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

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

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

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

接下來就等目標(biāo)訪問了。..。..

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

0x04 總結(jié)

總結(jié)一下測試水平越權(quán)漏洞的基本思路：

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

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

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

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