Mock 簡述

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

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

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

需要 Mock的場景

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

Mock 工具

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

然后編輯期望的返回類型和返回值，同時可以設置匹配的路徑，匹配的請求方法等。

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

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

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

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

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

下面舉個例子

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

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

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

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

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

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

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

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

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

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

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

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

無法注冊的后臺賬號/內(nèi)部員工賬號

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

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

總結(jié)

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