Mock 簡述

Mock 這個(gè)詞在軟件測試行業(yè)較為常用。Mock方法是單元測試中常見的一種技術(shù), 它的主要作用是模擬一些在應(yīng)用中不容易構(gòu)造或者比較復(fù)雜的對(duì)象,例如模擬某個(gè)接口在特殊情況下的返回值。亦或者前/后端測試團(tuán)隊(duì)用于檢驗(yàn)數(shù)據(jù)返回和展示數(shù)據(jù)是否滿足期望值。

目前有很多開源或者商業(yè)Mock平臺(tái)，例如阿里媽媽前端團(tuán)隊(duì)出品的RAP就是一款出色的接口文檔管理和MOCK平臺(tái)。

RAP通過GUI工具幫助WEB工程師更高效的管理接口文檔，同時(shí)通過分析接口結(jié)構(gòu)自動(dòng)生成Mock數(shù)據(jù)、校驗(yàn)真實(shí)接口的正確性，使接口文檔成為開發(fā)流程中的強(qiáng)依賴。有了結(jié)構(gòu)化的API數(shù)據(jù)，RAP可以做的更多，而我們可以避免更多重復(fù)勞動(dòng)。

需要 Mock的場景

在滲透測試過程中，經(jīng)常會(huì)遇到權(quán)限控制，無法訪問到某個(gè)角色下的功能菜單。 因此本文會(huì)從兩個(gè)角度來說明MOCK是如何起作用的，并一起討論如何通過MOCK挖掘到更多的漏洞。首先要說明一下為什么滲透測試中也需要MOCK，一方面是為了繞過前端的限制，例如前端的timeout設(shè)置，抓包改包手動(dòng)來不及，另一方面是為了方便接口“造數(shù)據(jù)”——也就是有些接口的一些參數(shù)規(guī)則手動(dòng)構(gòu)造麻煩，在MOCK了前一個(gè)請(qǐng)求返回值后，下一個(gè)請(qǐng)求才會(huì)自動(dòng)拼接好參數(shù)請(qǐng)求，這樣就省去了自己看js 代碼構(gòu)造的麻煩。 俗話說“工欲善其事，必先利其器”，那就看看有哪些工具可以輔助我們測試。

Mock 工具

筆者分別在Proxyman和Burpsuite 這兩款抓包工具使用了MOCK功能/插件。在Proxyman 中，它是在Tools-Map Local (本地)和Tools-Map Remote (遠(yuǎn)程)。以Map Local 為例，我們可以選中感興趣的接口右鍵添加到Map Local/Remote。

然后編輯期望的返回類型和返回值，同時(shí)可以設(shè)置匹配的路徑，匹配的請(qǐng)求方法等。

下面演示了某系統(tǒng)前端根據(jù)result 的value 是否為true 來判斷是否可進(jìn)入到登錄后的index頁面，否則會(huì)提示用戶名和密碼錯(cuò)誤。如果通過手動(dòng)改包的話，會(huì)提示超時(shí)或者請(qǐng)求錯(cuò)誤，前端無法跳轉(zhuǎn)到登錄后的頁面。這個(gè)時(shí)候就可以通過MOCK將result的值修改為true ，這樣就進(jìn)入到系統(tǒng)從而進(jìn)一步進(jìn)行測試，挖掘功能模塊是否存在未授權(quán)訪問等漏洞了。

還有些系統(tǒng)的權(quán)限資源是根據(jù)接口返回的資源路徑來做展示的，例如會(huì)請(qǐng)求https://testivy.local/resource/list，根據(jù)返回報(bào)文中的ifBinding來確定當(dāng)前登錄用戶是否具有該對(duì)應(yīng)菜單的權(quán)限，因此就可以MOCK這個(gè)ifBinding 全為true 就可以了訪問所有功能菜單了。

在BurpSuite中同樣也有MOCK插件，在插件市場安裝HTTP MOCK。

同樣在HTTP history 右鍵選中Mock HTTP response。

然后編寫期望的MOCK值，最后要點(diǎn)擊save 生效。(確認(rèn)Enabled 那欄是否選中)。

下面舉個(gè)例子

可注冊(cè)的低權(quán)限賬號(hào)/商家審核中的賬號(hào)

在測試過程中，當(dāng)核心系統(tǒng)或者面向C端用戶的系統(tǒng)被擼了個(gè)遍的時(shí)候，通常是很難找到漏洞的，即使能找到也多是一些重復(fù)的或者內(nèi)部已知的。因此柿子就要找軟的捏，哪種柿子好捏，一種是面向商家的系統(tǒng)，但這種系統(tǒng)的特點(diǎn)也很明顯，要么就是可以注冊(cè)但是必須提交各類證件，例如法人身份zheng，營業(yè)執(zhí)照等后臺(tái)人員審核通過后才能使用商家系統(tǒng)的功能;要么就是商務(wù)合作之后分配的賬號(hào)，沒有注冊(cè)入口。首先我們來說可以注冊(cè)但需要審核的商家賬號(hào)吧。

首先來看下提交資質(zhì)文件審核的一般流程：

通常這類商家資質(zhì)材料需要營業(yè)執(zhí)照、法人身份zheng、法人姓名、門頭照、開戶行等，能夠正確準(zhǔn)備這些材料并且順利通過審核還是難的。尤其對(duì)于我們想快速測試下接口漏洞來說，時(shí)間就是金錢。因此通過MOCK 可以快速測試審核通過后有哪些功能模塊以及相應(yīng)接口是否存在可挖掘的漏洞。

比如某系統(tǒng)需要提交一些資質(zhì)信息進(jìn)行審核，審核通過才具有商家功能。

(圖片中的數(shù)據(jù)為示例數(shù)據(jù))

由于這個(gè)系統(tǒng)是人工進(jìn)行審核的，而且提交過幾次都是被打回來了，審核不通過。這個(gè)時(shí)候想到用MOCK下。

首先打開首頁的時(shí)候是有一個(gè)接口請(qǐng)求當(dāng)前商家狀態(tài)的，是未提交、審核中還是審核通過狀態(tài)。 發(fā)現(xiàn)查詢審核狀態(tài)接口：/**/company/detail/v2 這個(gè)時(shí)候可以把這個(gè)接口進(jìn)行MOCK，在proxyman 中對(duì)應(yīng)的是Map。將狀態(tài)改成6(審核中是1，待審核是0)，可以通過js (在js 搜“待審核”，找到對(duì)應(yīng)的代碼行位置，然后就能輕松找到“已審核”對(duì)應(yīng)的狀態(tài)碼了—狀態(tài)碼是6)

(圖片中的數(shù)據(jù)為示例數(shù)據(jù))

由于商家通過審核，前端一般會(huì)展示出對(duì)應(yīng)的功能，如果后續(xù)還有新的接口校驗(yàn)商家狀態(tài)的，也一樣進(jìn)行MOCK。這樣就方便了針對(duì)接口的參數(shù)構(gòu)造，省去了一行行看代碼的煩惱，而你只需要做的就是點(diǎn)點(diǎn)，獲取完整請(qǐng)求參數(shù)后再進(jìn)行工具掃描。 通過上面的MOCK過程，就可以順利進(jìn)入到合同頁面：

接下來，我們可以找到對(duì)應(yīng)模塊的功能點(diǎn)開始“大刀闊斧”了。這里可能很多人會(huì)有疑問，有很多工具可以從js 提取接口，這樣多麻煩。這在前面的文章《現(xiàn)代前后端分離式應(yīng)用API滲透測試探究》已經(jīng)討論過。

接下來再看下另外一種場景。

無法注冊(cè)的后臺(tái)賬號(hào)/內(nèi)部員工賬號(hào)

針對(duì)這類系統(tǒng)，由于沒有注冊(cè)入口，通常都是管理員或者內(nèi)部員工才能登錄。這個(gè)地方MOCK 的難度在于不知道應(yīng)該如何找對(duì)參數(shù)。一些簡單的系統(tǒng)根據(jù)Response 中的resultCode 是true 還是false 決定是否跳轉(zhuǎn)到后臺(tái)頁面，但有些系統(tǒng)相對(duì)來說是有些復(fù)雜的，這個(gè)時(shí)候就要看一看js了，需要花費(fèi)一點(diǎn)時(shí)間。

以上內(nèi)容如有錯(cuò)誤之處，還請(qǐng)大家不吝指出。

總結(jié)

MOCK可以輔助我們安全測試，正所謂”通則變，變則通“，安全亦如此。