鑽石舞台

作者：一線卑微安服仔

原文地址：https://www.freebuf.com/vuls/313396.html

本篇是對今年滲透測試遇到的越權攻擊進行一下總結，下面總結的照片實例，均已進行脫敏處理，可放心食用。

前言

從狹義上講越權訪問，是攻擊者在獲得低權限用戶的賬戶後，可以利用一些方式繞過權限檢查，訪問或者操作到原本無權訪問的高權限功能。

這類漏洞往往很難通過工具進行自動化檢測，屬於邏輯漏洞中的一種，目前存在着兩種越權操作類型，如下圖所示：

橫向越權：攻擊者嘗試訪問與他擁有相同權限的用戶的資源

示例：購物系統中A用戶可以可以查詢到B用戶的訂單信息。

縱向越權：攻擊者可以使用低權限的賬戶去使用高權限賬戶的功能。

示例：原本沒有刪除功能的用戶A可以使用管理員用戶的刪除功能刪除了管理員用戶中的數據。

但是從廣義上講還包括一種「未授權攻擊」，這種漏洞類似于越權攻擊中的縱向攻擊，攻擊者沒有獲取到登錄權限或未授權的情況下，或者不需要輸入密碼，即可通過直接輸入網站控制台主頁面地址，或者不允許查看的鏈接便可進行訪問，同時進行操作。

無論是在我日常滲透測試中還是在自身參加的眾測項目中，因鑒權不當產生的越權攻擊也越來越多。

對於廠商來說，此類問題危害性極大，攻擊者可以突破登錄、身份驗證等手段控制後台功能或越權到高權限身份。

所以這篇文章我將從幾種場景的角度來展開介紹實戰中的越權攻擊。

攻擊場景登錄

1未授權訪問

未授權訪問也可大致分為三種，第一種是直接通過修改響應碼的狀態，第二種通過直接鏈接訪問從而繞過登錄限制，第三種人為疏忽的導致的問題。

1.1修改響應碼登錄

不同系統採用的響應碼各不相同，一般都是通過抓包查看JS文件，來判斷如何修改。也可以採用簡單粗暴的方式，例如直接登錄查看正確的響應碼或者是直接猜！

常見響應碼：200、000000、true、0、success、ok、1等等（排名不分先後，全憑個人經驗）

示例：

JS文件可以查找到準確的響應碼

註：

在正確設置後端檢驗的情況下，即使修改響應碼後，仍然會跳回登錄界面。而可以通過修改狀態碼進行登錄的，一般分為以下兩種類型：

第一種：後端未作驗證，修改狀態碼就可以直接繞過權限檢查，可定級為高危漏洞。

第二種：後端做了驗證，修改狀態碼後仍然會顯示後台頁面，或是泄露後台部分的功能接口，但是沒有數據和操作權限，可定級為低中危。

修複方式：

修改驗證邏輯，如是否登錄成功服務器端返回一個參數，但是到此就是最終驗證，不需要再對返回的參數進行使用並作為登錄是否成功的最終判斷依據。

1.2 URL的直接訪問

一般通過目錄掃描、FUZZ、猜解等方式獲取到後台路徑從而達到直接訪問後台功能的目的或者是使用JSFinder搜索源代碼中調用的地址（成功率很高，強烈推薦）

Tips:

目錄掃描工具推薦使用Dirmap、Dirsearch，個人比較推薦使用Dirmap加字典的方式。

JSFinder：推薦使用Tampermonkey下的腳本。

若甲方提供測試賬戶，可以先行登錄獲取部分鏈接，然後待退出登錄消除憑證後，查看是否能重新訪問這部分鏈接。

示例:

直接訪問JSFinder爬取到鏈接，查看是否存在未授權的情況

註：

掃描目錄的時候除了未授權的後台頁面，也需要同時關注以下幾種漏洞：目錄遍歷、任意文件上傳下載、API接口泄露。

修複方式：

禁止目錄掃描，並提前做好自我檢查，使用遞歸的方式檢查自己的目錄以及檢查網頁中的站點是否存在未授權的路徑。

1.3 密碼直接暴露

這裡需要注意的是下面示例中賬戶本下載的情況並不多見，較多情況是直接編寫在前端源碼中，例如「密碼提示框」中或是單純的隱藏在源碼，因此在測試的時候需要注意關注網頁源代碼。

示例：

這個案例是將賬號本鏈接暴露在前端，從而導致攻擊者直接獲取了登錄的賬戶密碼。

在登錄界面可以發現存在一個「賬號名單」，嘗試下載

點擊「賬戶名單」後下載的密碼本

修複方式：

同樣是提前做好自我檢查，檢查是否存在是不是違規或者是敏感的信息泄露。

2. 身份信息/登錄信息偽造

開發者為了方便將身份信息/登錄信息明文或者只是簡單編碼、加密之後存放在鏈接中或是數據包中，網站通過這些信息進行授權或者身份驗證。

常見測試就是修改URL和響應包中鑒權參數造成的，鑒權參數大抵就是id、username、login、session、cookie、token等。例如某些系統修改Login=1、修改UserName=admin均可以被系統判定為管理員登錄。

註：

此處的加密特指MD5加密，也有極少數能同時泄露密碼、公私鑰的加密算法。

示例1：

這個案例是通過直接添加token字段的UUID值來構成未授權訪問

示例2：

這個案例就可以從響應包準確的看到加密算法為：AES，加密模式：CBC，填充：zeropadding，數據塊：128位，密碼：XXX，偏移量為：XXX。

只有同時集齊這麼多信息才能破解登錄數據。

qqaAAAAAAAAAAAAA`

Tips:

常見的解碼網址：

URL解碼：http://www.jsons.cn/urlencode/

Base64解碼：https://base64.us/

MD5解碼：https://cmd5.com/

AES解密：http://tool.chacuo.net/cryptaes

以及個人使用頻率很高的utools解編碼插件，由於utools的快速呼出機制，因此在這裡解碼尤為方便。

PS：這東西簡直是安服居家旅行必備好物，牆裂推薦！這裡面還有很多小插件，有興趣的話大家可以繼續探索。

數據

在這一場景下，基本都是登錄的情況下，因此參數也不在局限於身份信息了，更多的為手機號、ID number、卡號、員工編號、日期、賬單編號，還有部分是自定義的參數，極少數是通過插入隨機數然後取特定的幾位數（防禦較好的站點這些部分仍然會被進行加密），如下圖所示：

當然也有部分個例採用的是JWT方式隱藏特定參數，然後通過解密進行校驗。

從當前測試的站點來看，數據層面出現的越權占據越權的一半以上，而這一半中至少80%為橫向越權。

而數據層面也大致分為以下三種：身份信息偽造、數據篡改、流程越過

1. 身份信息偽造

與上同，這部分仍然是對身份信息的校驗，這部分的信息使用明文或者只是簡單編碼、加密進行存放都有可能構成越權。

示例1：

首先我們通過一個賬戶A在此接口進行查詢，通過分析數據包就可以發現參數accountNo為身份控制參數。

在此接口查看賬戶B，此處由於賬戶原因，導致沒有賬戶明細，但是已經顯示可以成功查詢

示例2：

與示例1的情況基本相同，此時的身份控制參數直接出現的URL中，可以更加便捷的發現越權情況。

使用賬戶A查詢，發現出現自定參數partnerId

在此接口遍歷參數partnerId，成功返回其他賬戶信息。

註：

關於鑒權參數的檢查是貫穿整個測試流程的，望各位師傅謹記。每個功能點都有可能因為鑑權失效而構成越權攻擊。

修複方式：

身份信息必須進行加密傳輸，要採取標準的加密方式進行加密，並保存好密碼，儘量不要使用base64編碼，即使使用base64傳輸，也需要加入髒數值來進行混淆，儘可能的增加攻擊者破解的難度。

2. 數據篡改

常見的數據修改一般為正負值反衝、修改訂單數據、修改商品ID等，以前憧憬一分錢買一大堆零食，現在幹了就喜提白銀手銬一副。值得注意的是，例如sendXX、XXmessage這部分可以進行接口的爆破，以此來構成短信/郵件轟炸。

參數大多為：value 、price 、amount 、number 、XXID、pid 等。

示例：

通過修改參數值以達到越權增刪改查的橫向越權漏洞

抓包截取當前的數據包，通過修改Price的相關參數，均修改為負數，從而來構造惡意的請求

可以看到此處的價格已經被成功修改

修複方式：

針對數據的越權修改也有較為成熟的修複方法，可以根據商品ID、訂單金額等數據生成這個訂單專屬哈希值，驗證的時候服務器需要根據當前數據包內金額再次生成哈希值與第一次做匹配；

除此之外，一些特定的機構還可以額外添加大額交易人為審核的措施，保證資金安全。

3. 流程越過

攻擊者越過中間校驗步驟直接進行後續操作，導致中間校驗等步驟失效。

通常的測試思路基本就是，首先完成正常的業務邏輯步驟，獲取每一個步驟的請求，再繞過中間步驟直接訪問最後一個或幾個的驗證請求，查看是否能成功請求。

流程越過在密碼修改/重置處、購買商品上出現的比較頻繁，各位師傅可以重點留意這些測試點。

示例：

這個案例就是通過直接訪問最後一個接口信息，來達成的流程越過。

正常邏輯下完成付款步驟

代碼部分

從源碼可以看出通過訪問接口/shoufei，就可以直接完成繳費請求

下面嘗試跳轉邏輯

重複上述操作，再次添加一次100元的CT項目

然後直接訪問/shoufei接口,此處的33，就是上述步驟中的訂單據號

返回數據幾即表示繳費多少條訂單，這裡只有一個訂單，因此返回1

修複方式：

在每個步驟的session都應該添加標識位，並將session與用戶的身份進行強綁定並且在新步驟顯示之前必須要檢測之前每一步的 session標誌位。

而關於密碼修改的地方還可以使用一次性填寫所有的校驗信息，例如原始密碼、新密碼等信息後再提交修改/重置密碼請求。

總結

在日常的測試中需要關注任何場景每一個可能決定用戶權限的參數值，注意GET、POST的傳參，把握傳參，就能把握住越權的命脈。

當然，還有一些常見的測試方式：

當對一個有註冊功能或是存在身份認證的站點，可以申請兩個不同賬戶來進行橫向越權測試，如果甲方爸爸同意的話，最好是提供一個管理員權限的賬戶和兩個普通的賬戶，以此來完成完整的縱橫越權測試。例如使用賬號C的token或者是cookie去替換賬戶A的信息來測試功能。

分析每個參數的功能，儘可能的多去嘗試修改，例如任意加減參數值或將false修改為true/success會發生什麼、執行某一操作的時候刪除 Cookie或 Token後是否仍能觸發功能。

同時，我們也可以思考一下：

A拿A的鑰匙，開B的鎖，這叫鎖有問題。A拿B的鑰匙，開B的鎖，鎖還有問題麼?

大門裡的東西，包含小門裡的東西，如果大門進去能夠看到小門的東西，算不算問題？如果小門進去能看到小門裡面東西之外的其他大門所有東西，算什麼問題？

A、B兩個不同的門，進去的東西不相同，A門進去之後有辦法看到B門的東西，算什麼問題？

Tips：

火狐插件Multi-Account Containers可以提高平時我們測試時候的效率，它通過使用不同的容器，讓不同的顏色來區分不同的賬戶。

追根結底，越權漏洞的本質就是看到當前用戶本不該看到的數據，執行本不該執行的操作。

歡迎關注LemonSec

覺得不錯點個「贊」、「在看」哦