如何使用Postman更好的進(jìn)行API滲透測(cè)試

這篇文章將為大家詳細(xì)講解有關(guān)如何使用Postman更好的進(jìn)行API滲透測(cè)試，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

拜泉網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),拜泉網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為拜泉數(shù)千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營(yíng)銷(xiāo)網(wǎng)站建設(shè)要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的拜泉做網(wǎng)站的公司定做！

在這個(gè)時(shí)代，Web 和移動(dòng)應(yīng)用程序通常是由 RESTful 網(wǎng)絡(luò)服務(wù)提供支持的。 公共和私有 API 在互聯(lián)網(wǎng)上非常普遍，測(cè)試這些 API 絕非易事，但有一些工具可以幫助你。 雖然(通常用與滲透測(cè)試)工具不能代替技能，但即使是最熟練的木匠也能用錘子比用鞋子更有效地釘釘子。

Postman 就是這樣一個(gè)工具，它在開(kāi)發(fā)者中已經(jīng)流行了很多年。 在我們進(jìn)入如何設(shè)置它的主題之前，我們先來(lái)快速介紹一下這個(gè)工具是什么以及可以做什么。 Postman 是一個(gè)商業(yè)桌面應(yīng)用程序，可用于 Windows、 Mac OS 和 Linux。 它的大部分功能是免費(fèi)的，也有付費(fèi)的功能，比如提供協(xié)作和文檔功能。 與滲透測(cè)試人員相比，這些特性對(duì)開(kāi)發(fā)人員更有意義。 它用于管理測(cè)試各種 API 調(diào)用的 HTTP 請(qǐng)求集.合，以及包含變量的環(huán)境。 它并不能替代你的代理(如：Burp，ZAP，Mitmproxy 等等) ，但是實(shí)際上彌補(bǔ)了瀏覽器和客戶端應(yīng)用程序?qū)尤笔У墓δ堋?對(duì)于這款工具主要的替代方案是開(kāi)源工具 Insomnia 和高級(jí) REST 客戶端，商業(yè)產(chǎn)品 SoapUI，或建立在 Swagger/Swagger UI 或 curl 的自定義工具。

設(shè)置 Postman

在其官方網(wǎng)站上（https://www.getpostman.com,）可以找到 Postman，提供 Windows 和 MacOS 的安裝程序，以及 Linux 的 tar 包。 它也可以在 Ubuntu 的 Snap for Ubuntu ( HTTPs://snapcraft.io/postman )和其他社區(qū)維護(hù)的 repos 中找到，比如 Arch Linux 的 AUR。 設(shè)置它的第一步當(dāng)然是程序安裝。

在第一次啟動(dòng) Postman 時(shí)，你會(huì)看到一個(gè)屏幕，提示你創(chuàng)建一個(gè)帳戶，注冊(cè)谷歌，或者用現(xiàn)有的憑證進(jìn)行登錄。 然而， Postman 并不需要一個(gè)帳戶來(lái)執(zhí)行后續(xù)的使用。

登錄的帳戶用于協(xié)作/同步/等; 這些是付費(fèi)的功能。正如我前面提到的，這幾個(gè)功能對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)很棒，但對(duì)你來(lái)說(shuō)，可能并不關(guān)心。 事實(shí)上，如果你通常需要對(duì)你的客戶端機(jī)械能保密，就像我們?cè)?Secure Ideas 所做的事情，那么你可能明確地不希望將你的項(xiàng)目同步到另一個(gè)第三方服務(wù)器。

如果你低頭看窗口的底部，你會(huì)看到一些淺灰色的文字，上面寫(xiě)著跳過(guò)登錄，直接把我?guī)У搅藨?yīng)用程序界面。 點(diǎn)擊這個(gè)灰色的鏈接，你將移動(dòng)到下一個(gè)屏幕——一個(gè)提示你創(chuàng)建東西的對(duì)話框。

有幾個(gè)部分你不會(huì)在這里使用到，所以讓我們看看你真正關(guān)心的三個(gè)功能:

• 集.合（Collection）——一個(gè)你可以用請(qǐng)求填充的通用容器。 它還可以作為一些配置選擇的頂級(jí)對(duì)象，比如身份驗(yàn)證規(guī)則(Authentication rules) ，我們稍后將對(duì)其進(jìn)行詳細(xì)說(shuō)明。

• 請(qǐng)求（Request）——這個(gè)是最主要的功能。 這些是你將要構(gòu)建的 HTTP 請(qǐng)求，使用你想要使用的任何方法、HTTP Body等。 這些必須始終在一個(gè)集.合中。

• 環(huán)境（Environment） ——這里可以保存你希望在某個(gè)地方控制并發(fā)出跨請(qǐng)求甚至跨集.合所使用的變量。

使用 Postman 的基本知識(shí)

是時(shí)候創(chuàng)建我們的第一個(gè) Postman 集.合并發(fā)出 HTTP 請(qǐng)求。

左上角的 New 按鈕通常用于創(chuàng)建集.合和請(qǐng)求。 讓我們首先創(chuàng)建一個(gè)集.合。 這有點(diǎn)像一個(gè)單獨(dú)的應(yīng)用程序。 你將用于對(duì)相關(guān)請(qǐng)求進(jìn)行分組。

集.合還可以作為具有身份驗(yàn)證指令的頂級(jí)項(xiàng)，這些身份驗(yàn)證指令將對(duì)單個(gè)請(qǐng)求進(jìn)行繼承。 現(xiàn)在，只要給它起個(gè)名字，然后點(diǎn)擊創(chuàng)建按鈕就行了。 這里，我起的名字是“測(cè)試集.合”。

默認(rèn)情況下，你已經(jīng)打開(kāi)了一個(gè)未命名的請(qǐng)求選項(xiàng)卡。 讓我們來(lái)看看 UI 的這一部分。

1. 活動(dòng)選項(xiàng)卡

2. 此請(qǐng)求的名稱(chēng)。 這只是一些描述性的名稱(chēng)，你可以寫(xiě)也可以不寫(xiě)。

3. HTTP 方法。 這個(gè)下拉控件允許你更改此請(qǐng)求的方法。

4. 請(qǐng)求的 URL。 這是完整的路徑，就像在你的瀏覽器的地址欄一樣。

5. 用于設(shè)置請(qǐng)求的各種屬性的選項(xiàng)卡式界面，包括參數(shù)、HTTP 頭、HTTP 主體等。

6. 發(fā)送按鈕。 這實(shí)際上是將請(qǐng)求提交到指定的 URL。

7. 保存按鈕。 第一次單擊此選項(xiàng)時(shí)，你需要指定你的集.合，因?yàn)檎?qǐng)求必須屬于某個(gè)集.合。

我在 HTTP://localhost:4000上設(shè)置了一個(gè)示例目標(biāo)，所以我將從填寫(xiě)這個(gè)請(qǐng)求并保存到我的某個(gè)集.合作為開(kāi)始。我將發(fā)出一個(gè) POST 請(qǐng)求，到 HTTP://localhost:4000/legacy/auth ，沒(méi)有任何參數(shù)(這是一個(gè)測(cè)試 API。 任何人都可以通過(guò)身份驗(yàn)證)。 當(dāng)我點(diǎn)擊保存按鈕時(shí)，我將命名請(qǐng)求并為它選擇一個(gè)集.合，如下圖所示：

然后單擊"保存到測(cè)試集.合"(根據(jù)你的集.合名稱(chēng)進(jìn)行調(diào)整)按鈕來(lái)保存我的請(qǐng)求。 現(xiàn)在，單擊 Send 按鈕將發(fā)出請(qǐng)求。 然后我將看到響應(yīng)填充在窗口的下窗格中，如下圖所示：

1. 選項(xiàng)卡界面有 Body , Cookies , Headers 及測(cè)試結(jié)果。 我們還沒(méi)有編寫(xiě)任何測(cè)試，但是請(qǐng)注意圖中標(biāo)出的響應(yīng)返回的cookie ，headers。

2. 實(shí)際響應(yīng)的 HTTP Body 位于較大的文本窗格中。

3. 我們有可讀性較好的打印方法或原始的響應(yīng)主體的選項(xiàng)，以及不同類(lèi)型的下拉列表(我相信這是預(yù)填充的響應(yīng)頭 content-type)。這里還有一個(gè)自定義包裝按鈕，以防你有其他特殊的操作。

4. 關(guān)于響應(yīng)的衡量標(biāo)準(zhǔn)包括 HTTP狀態(tài)碼、響應(yīng)時(shí)間和響應(yīng)大小。

關(guān)于 Cookies 的一個(gè)旁注

現(xiàn)在，如果我們使用 Postman 重新發(fā)出請(qǐng)求，我們將注意到一個(gè)重要的事情: 之前在響應(yīng)中設(shè)置的 cookie 會(huì)被自動(dòng)包含。 它模仿了瀏覽器通常為你做的事情。 正如你對(duì)瀏覽器的期望一樣，在這個(gè) cookie 范圍內(nèi)發(fā)出的任何請(qǐng)求，Postman 都將自動(dòng)包含該 cookie。

如果你想移除某個(gè) cookie 該怎么做呢？ 這很簡(jiǎn)單。 在 Postman 的發(fā)送按鈕下面，有一個(gè)類(lèi)似鏈接的按鈕，上面寫(xiě)著 Cookies。 點(diǎn)擊這個(gè)按鈕，會(huì)打開(kāi)一個(gè)對(duì)話框，在那里你可以刪除或編輯任何你需要的 cookies。

這就是基于 cookie 的 API。 但是讓我們面對(duì)現(xiàn)實(shí): 現(xiàn)在我們常見(jiàn)的 API 都會(huì)使用無(wú)記名令牌（Bearer Token）這比使用 Cookies 更為普遍。

為什么要設(shè)置代理？

通過(guò)使用 Postman，我們可以將其作為一個(gè)優(yōu)秀的工具，從零開(kāi)始制作請(qǐng)求并管理這些請(qǐng)求。 通過(guò) Burp 代理 Postman 的流量，我們可以得到這些好處: 我們可以與Burp 的 intruder 功能結(jié)合進(jìn)行模糊測(cè)試，我們也可以利用 Burp 的被動(dòng)掃描器檢測(cè)突出的安全問(wèn)題，我們也可以利用 Burp 的擴(kuò)展插件，這一部分我們將在本系列文章的后續(xù)章節(jié)中看到。 而且我們可以使用Burp 的 Repeater 篡改請(qǐng)求。 或許你會(huì)說(shuō)，我們也可以在 Postman 里面進(jìn)行篡改啊。 但是我要說(shuō)的是使用 Repeater 有兩個(gè)重要的原因: 1) Postman 的設(shè)計(jì)是用于發(fā)出正確、有效的請(qǐng)求。 在某些情況下，它會(huì)嘗試糾正格式不正確的語(yǔ)法。 而在測(cè)試安全問(wèn)題時(shí)，我們可能不希望它糾正我們篡改的錯(cuò)誤。 2)通過(guò)使用 Repeater，我們保持了在 Postman 中的請(qǐng)求的干凈狀態(tài)以及在 Repeater 中已篡改的請(qǐng)求這兩者之間的分離。

設(shè)置 Burp Suite

對(duì) Burp 的實(shí)際介紹超出了這篇文章的范圍。 如果你正在閱讀這篇文章，很可能你已經(jīng)對(duì)它很熟悉了

現(xiàn)在，啟動(dòng) Burp，檢查 Proxy 下的 Options 選項(xiàng)卡。 最上面的部分是代理監(jiān)聽(tīng)器（Proxy Listeners），你應(yīng)該會(huì)在127.0.0.1和端口8080上看到一個(gè)監(jiān)聽(tīng)器。 它必須一直運(yùn)行(注意復(fù)選框)。 如果它在默認(rèn)情況下沒(méi)有運(yùn)行，那通常意味著端口不可用，你需要將監(jiān)聽(tīng)器(以及Postman)更改為不同的監(jiān)聽(tīng)端口。 只要將 Burp 正在監(jiān)聽(tīng)的端口以及你在 Postman 中設(shè)置的代理的地址和端口是同一個(gè)，那么你的設(shè)置應(yīng)該沒(méi)什么問(wèn)題。

同時(shí)檢查 Proxy 下的 Intercept 選項(xiàng)卡并驗(yàn)證 Intercept 是否關(guān)閉。

在 Postman 中配置 Burp 代理

Postman 是代理感知的，這意味著我們要將它指向我們的中間人代理，也就是 Burp Suite。 我們將通過(guò)點(diǎn)擊右上角的扳手圖標(biāo)(1)打開(kāi)設(shè)置對(duì)話框，然后點(diǎn)擊下拉菜單上的設(shè)置選項(xiàng)(2)。 這會(huì)打開(kāi)一個(gè)比較大的設(shè)置對(duì)話框，在頂部有不同類(lèi)別設(shè)置的標(biāo)簽。 找到"代理"選項(xiàng)卡并單擊進(jìn)行設(shè)置。

打開(kāi) Postman 設(shè)置面板

在這個(gè)標(biāo)簽頁(yè)上有三件事可以做:

1. 打開(kāi)全局代理配置開(kāi)關(guān)（Global Proxy Configuration）

2. 關(guān)閉"使用系統(tǒng)代理（Use System Proxy）"開(kāi)關(guān)

3. 將代理服務(wù)器 IP 地址和端口設(shè)置為和你在 Burp Suite 代理中設(shè)置的一樣

默認(rèn)的代理接口是127.0.0.1，端口是8080，這里假設(shè)你的 Postman 和你的 Burp Suite 是在同一臺(tái)機(jī)器上運(yùn)行的。 如果你想使用不同的端口，你需要在這里指定它，并確保它被設(shè)置為與 Burp 中的代理接口一樣。

現(xiàn)在你可以代理流量了，還有一個(gè)問(wèn)題需要考慮。 如今，大多數(shù)公共 API 都使用了 SSL/TLS 。 這是一件非常好的事情，但它也意味著當(dāng) Burp 作為代理中間人在處理 Postman 的 API 請(qǐng)求和響應(yīng)時(shí)，你會(huì)遇到證書(shū)錯(cuò)誤的問(wèn)題，除非你的系統(tǒng)已經(jīng)信任了 Burp 的證書(shū)頒發(fā)機(jī)構(gòu)。 解決這個(gè)問(wèn)題有兩個(gè)方法:

1. 你可以關(guān)閉 Postman 中的證書(shū)驗(yàn)證。 在 General 設(shè)置選項(xiàng)卡下面有一個(gè) SSL 認(rèn)證驗(yàn)證選項(xiàng)。 設(shè)置為 關(guān)掉（Off），將使 Postman 忽略任何證書(shū)問(wèn)題，包括 Burp Suite 的 PortSwigger CA 。

2. 你可以將你的Burp Suite CA 設(shè)置到系統(tǒng)信任存儲(chǔ)。 具體的設(shè)置細(xì)節(jié)和平臺(tái)有關(guān)系。
   

驗(yàn)證代理是否正常工作

用 Postman 發(fā)出一些請(qǐng)求。 在 Burp 的 Proxy 選項(xiàng)卡上檢查你的 HTTP 歷史記錄。

在 Burp Suite 中的代理歷史記錄

故障排除

• 你發(fā)出的請(qǐng)求存在拖延和超時(shí)問(wèn)題？ 在 Burp 中的代理選項(xiàng)卡上檢查"攔截"是否關(guān)閉。 檢查 Postman 中的代理設(shè)置是否與 Burp 中的代理接口相匹配。

• Postman 收到了響應(yīng)，但響應(yīng)沒(méi)有顯示在 Burp 的代理歷史中（等等）？ 打開(kāi) Postman 的”設(shè)置"界面，檢查"全局代理配置"是否打開(kāi)。 確保你沒(méi)有激活 Burp 歷史記錄的過(guò)濾器來(lái)過(guò)濾掉你所有的請(qǐng)求。 如果沒(méi)有捕獲過(guò)濾范圍外的流量，模擬還要確保是否在 Burp 中設(shè)置了范圍（scope）。

現(xiàn)在我們已經(jīng)做好了基本的工具鏈設(shè)置。

集.合變量

Postman 中的變量幾乎可以用于請(qǐng)求中的任何字段。 語(yǔ)法是在它們的兩邊使用兩層花括號(hào)。有幾個(gè)地方我可以使用變量定義它們。 如果它們是靜態(tài)的，也許我會(huì)將它們?cè)O(shè)置為集.合變量。 例如，我一直使用 http://localhost:4000作為我的測(cè)試主機(jī)。 如果我將測(cè)試 API 的端口從4000改為4001，我不希望一個(gè)個(gè)編輯每個(gè)請(qǐng)求的 URL。接下來(lái)我介紹一下我們?cè)撊绾螌⑺苿?dòng)到一個(gè)集.合變量中。首先，在菜單側(cè)欄中打開(kāi)"集.合"列表中編輯該集.合的對(duì)話框。 我可以單擊… 按鈕或者右鍵單擊集.合名稱(chēng)。這兩種操作，我們會(huì)得到相同的上下文菜單，然后選擇編輯（Edit）。

這將打開(kāi)一個(gè)編輯集.合的對(duì)話框。 默認(rèn)視圖包括集.合的名稱(chēng)和描述的文本框，但是在這兩個(gè)字段之間還有一行選項(xiàng)卡。

其中一個(gè)標(biāo)簽叫做變量（Variables）。這就是我們想要的，點(diǎn)擊這個(gè)標(biāo)簽會(huì)打開(kāi)另一個(gè)對(duì)話框，用于編輯變量。

Postman 集.合變量編輯界面

它有一個(gè)表格，其中包含某個(gè)變量的變量名稱(chēng)、 初始值列和 當(dāng)前值列。 這兩個(gè)值列之間的差異與 Postman 的付費(fèi)功能進(jìn)行同步有關(guān)。 在這里重要的一個(gè)點(diǎn)是，你將輸入初始值，然后選項(xiàng)卡進(jìn)入當(dāng)前值字段。 這將自動(dòng)將當(dāng)前初始值填充到當(dāng)前值字段中，并且它將如圖所示。 現(xiàn)在我有了一個(gè)名為 API_host 的集.合變量，其值為 http://localhost:4000。 在完成了變量的編輯之后需要點(diǎn)擊更新按鈕。

現(xiàn)在是時(shí)候修改我的請(qǐng)求，并引用該變量，而不是使用硬編碼的主機(jī)名和端口。

Postman中的請(qǐng)求，將URL更改為指向一個(gè)變量

我只是簡(jiǎn)單地用占位符替換了每個(gè) URL 中對(duì)應(yīng)的部分:  {{API_host}}，把鼠標(biāo)懸停在占位符上可以展開(kāi)這個(gè)變量，會(huì)顯示變量值和范圍。 這里有一些顏色編碼也可以幫助我們。 當(dāng)變量有效時(shí)，文本會(huì)變成橙色，但是如果我輸入一個(gè)無(wú)效的變量名，文本將變成紅色。

我仍然需要對(duì)每個(gè)請(qǐng)求進(jìn)行一次更新，讓它們使用某個(gè)變量。 但是在將來(lái)，如果我改變了端口，或者如果我切換到了 HTTPS，或者如果我將我的測(cè)試 API 部署到一個(gè)完全不同的主機(jī)上; 那么我就可以回到集.合變量那里并更新變量的值，我的所有請(qǐng)求都會(huì)相應(yīng)地發(fā)生改變。

現(xiàn)在，集.合變量對(duì)于相對(duì)靜態(tài)的字段以及不會(huì)經(jīng)常發(fā)生改變的字段是很適合的，但是如果我在一個(gè)多租戶的解決方案中測(cè)試多個(gè)環(huán)境和部署，甚至多個(gè)租戶呢？ 我可能會(huì)使用相同的請(qǐng)求集.合，但是使用不同的變量集.合。 那么在這種情下環(huán)境變量就可以處理這個(gè)問(wèn)題。

環(huán)境變量（Environment Variables）

你可能已經(jīng)注意到了窗口右上角的界面。 讓我們打開(kāi)看看:

在 Postman 中的環(huán)境變量界面

1. 環(huán)境選擇器下拉菜單。可以選擇一個(gè)環(huán)境。

2. 快速查看按鈕，點(diǎn)擊后可以查看你的環(huán)境中設(shè)置的內(nèi)容。

3. 管理環(huán)境按鈕，這里是真正進(jìn)行編輯環(huán)境的地方。

首先，我們需要點(diǎn)擊管理環(huán)境按鈕。 這會(huì)打開(kāi)一個(gè)較大但空白的對(duì)話框，底部有一個(gè) Add 按鈕。 點(diǎn)擊這個(gè)添加按鈕。

你會(huì)看到另一個(gè)對(duì)話框。 這一個(gè)看起來(lái)幾乎和集.合變量對(duì)話框一樣，除了它有一個(gè)名字。

在這里，我把我的命名為 LocalTest。

我還添加了許多其他的變量，其中一個(gè)叫做bearer_token，值為 foo。 另一個(gè)是 user_id值為1。

一旦完成編輯，我們點(diǎn)擊對(duì)話框底部附近的添加按鈕，然后關(guān)閉管理環(huán)境對(duì)話框。 在我可以在這個(gè)環(huán)境中使用這個(gè)變量之前，還有最后一個(gè)重要的、經(jīng)常被忘記的步驟：我們需要從環(huán)境選擇器下拉菜單中選擇這個(gè)環(huán)境。

現(xiàn)在這些額外的變量可以像上面的 API_host 變量一樣進(jìn)行訪問(wèn): {{bearer_token}} 和 {{user_id}}

路由參數(shù)

在現(xiàn)代API中使用路由參數(shù)是很常見(jiàn)的。這些是作為URL主路徑的一部分所提供的值。例如，考慮以下情況http://localhost:4000/user/42/preferences

這樣的URL中的數(shù)字42實(shí)際上是一個(gè)參數(shù)，很可能是本例中的用戶 ID。 當(dāng)服務(wù)器端應(yīng)用程序路由傳入請(qǐng)求時(shí)，服務(wù)端會(huì)提取該值，并使其隨時(shí)可用于最終處理請(qǐng)求和構(gòu)造響應(yīng)的函數(shù)。 這是一個(gè)路由參數(shù)。 這對(duì)于編輯參數(shù)或是在 Postman 中使用也比較簡(jiǎn)單。語(yǔ)法是將參數(shù)以冒號(hào)(:)后跟參數(shù)名的形式直接放入 URL 中。 對(duì)于 Postman 中的這個(gè)示例請(qǐng)求，我將其輸入為{{API_host}}/user/:userId/preferences。 然后，在請(qǐng)求的參數(shù)（Params）選項(xiàng)卡上，我可以看到它被列出并設(shè)置了具體的值。 在下圖中，我將其設(shè)置為在前面的環(huán)境變量中指定的user_id變量。

我也可以把我的變量直接寫(xiě)到URL中，但在我看來(lái)，這種方式更干凈。

無(wú)記名令牌（Bearer Tokens）

想象一下這樣一個(gè)場(chǎng)景: 你發(fā)出某種類(lèi)型的授權(quán)請(qǐng)求，它用一個(gè) bearer token 進(jìn)行響應(yīng)，然后你需要在所有其他請(qǐng)求中使用該令牌。 這樣做的手動(dòng)方式可能只是發(fā)出驗(yàn)證請(qǐng)求，然后從響應(yīng)中復(fù)制并粘貼令牌到另外一個(gè)環(huán)境變量。 所有其他的請(qǐng)求都可以使用這個(gè)環(huán)境變量。

這樣也可以正常發(fā)出請(qǐng)求，如果你有一個(gè)短期的令牌，那么這種做法可能會(huì)很痛苦。對(duì)于這個(gè)問(wèn)題，有一個(gè)更優(yōu)雅的解決方案。想想下面的響應(yīng):

我們已經(jīng)發(fā)出了請(qǐng)求，并且收到了一個(gè)包含令牌的 JSON 響應(yīng)。 現(xiàn)在，我想用自動(dòng)化的方式使用新的bearer token來(lái)更新我的環(huán)境變量。 在請(qǐng)求界面上，有幾個(gè)標(biāo)簽可以做到。 最右邊的一個(gè)叫做測(cè)試。 這主要用于自動(dòng)檢查響應(yīng)，以確定 API 是否失效，就像單元測(cè)試一樣。 但是我們可以通過(guò)一些 JavaScript 語(yǔ)句來(lái)達(dá)到我們的目的。

我添加上面的腳本，單擊保存，然后再次運(yùn)行我的請(qǐng)求。 似乎所有的事情都和第一次一模一樣。但是如果我使用快速查看（Quick Look）按鈕來(lái)查看環(huán)境變量時(shí)……

我們可以看到當(dāng)前值已經(jīng)被自動(dòng)更新。 這是第一步——我現(xiàn)在將值存儲(chǔ)在一個(gè)我可以輕松引用的地方，但是它不會(huì)將Bearer token 這個(gè)令牌放入我的請(qǐng)求中。 我有兩個(gè)方法。 第一個(gè)方法是，如果打開(kāi)請(qǐng)求的 Authorization 選項(xiàng)卡，我們可以從類(lèi)型下拉列表中設(shè)置一個(gè)Bearer token，并將其指向我的變量。

這種方法還不錯(cuò)，但是我需要在每個(gè)請(qǐng)求上都進(jìn)行相同的設(shè)置。但是每個(gè)新的請(qǐng)求的默認(rèn)授權(quán)類(lèi)型是繼承父類(lèi)身份驗(yàn)證（Inherit auth from parent）。在本例中，父類(lèi)是個(gè)集.合。因此，如果我將這個(gè)請(qǐng)求切換回默認(rèn)的類(lèi)型，那么我就可以進(jìn)入編輯集.合（Edit Collection）進(jìn)行設(shè)置(與我進(jìn)入Collection變量的上下文菜單相同) ，然后進(jìn)入Collection的Authorization選項(xiàng)卡。

這個(gè)功能展示的接口幾乎與請(qǐng)求中的 Authorization 接口相同，我可以以相同的方式設(shè)置身份驗(yàn)證到信息。 現(xiàn)在的不同之處在于它是在集.合中管理的。 在默認(rèn)情況下，我創(chuàng)建的每個(gè)新的請(qǐng)求都將包含該bearer token，除非我故意更改了該請(qǐng)求的類(lèi)型。 例如，我的身份驗(yàn)證請(qǐng)求可能不需要bearer token，因此我需要在請(qǐng)求的 Authorization 選項(xiàng)卡上將類(lèi)型設(shè)置為 No Auth。

偶爾，我會(huì)遇到一些應(yīng)用程序，需要從響應(yīng)中包含的XML或HTML主體中提取一些值。 在這種情況下，內(nèi)置的xml2Json 函數(shù)有助于解析響應(yīng)內(nèi)容。

使用 xml2Json 將 HTML 主體整合到 JSON 對(duì)象中

還有一個(gè)需要注意的功能是 Pre-request Script 選項(xiàng)卡，它使用相同的基本腳本接口。 正如你可能期望的那樣，它在請(qǐng)求發(fā)送之前執(zhí)行。 我的一些同事使用這個(gè)功能來(lái)設(shè)置bearer token令牌，這是一個(gè)完全有效的方法，只不過(guò)不是我平時(shí)所使用的方法。 當(dāng)你只是需要一次性操作的時(shí)候，這種方法也會(huì)很有幫助，盡管這種情況我一般遇不到。

設(shè)置 Jython

其中的一些擴(kuò)展需要在 Burp Suite中設(shè)置Python環(huán)境，而B(niǎo)urp Suite在默認(rèn)情況下是不配置Python環(huán)境信息的。如果你已經(jīng)配置過(guò)了，那么你可以繼續(xù)下面的操作。如果沒(méi)有配置過(guò)，你可以打開(kāi) Extender-Options 并設(shè)置Jython的獨(dú)立JAR的位置。如果你需要這個(gè)下載jar包，你可以從jython.org上找到。

設(shè)置好路徑后，導(dǎo)航到 BApp Store 選項(xiàng)卡，就可以開(kāi)始下載我們將要使用的擴(kuò)展插件了。我想重點(diǎn)說(shuō)明的兩個(gè)插件是JSON Web Token Attacker和Autorize。

現(xiàn)在讓我們更詳細(xì)地看看這兩個(gè)插件。

JSON Web Token Attacker

目前已經(jīng)有許多處理身份驗(yàn)證和授權(quán)的方法。JWT可能是現(xiàn)代API上最常用的方法。如果在下圖中檢查Bearer token，你將注意到我們正在使用的JWT的幾個(gè)明顯標(biāo)志:三個(gè)片段，由冒號(hào)字符分隔。Base64編碼的頭部和聲明部分，后面跟著加密簽名。

這個(gè)令牌可以很容易地在Burp suite內(nèi)置的解碼器中解碼。只需選擇令牌，Base64就可以解碼整段文本。上圖中的文本解碼后，如下:

{"alg":"HS256","typ":"JWT"}.{"userid":1,"tokenid":"fac15939-de30-481d-9d13-6ae89ecd7370","iat":1552444637,"exp":155244823N30.ü￠R￥?e4r-?￡m-3ì@

雖然 Burp的 Decoder可以用這種方式以最小的損壞對(duì)文本進(jìn)行解碼，但我希望對(duì)其進(jìn)行修改和重新編碼。這樣做將產(chǎn)生以下結(jié)果:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9LnsidXNlcmlkIjoxLCJ0b2tlbmlkIjoiZmFjMTU5MzktZGUzMC00ODFkLTlkMTMtNmFlODllY2Q3MzcwIiwiaWF0IjoxNTUyNDQ0NjM3LCJleHAiOjE1NTI0NDgyM04zMC7colISpedlNHItBvijbS0TmYWzzIFAAOmykTIWurMtDzVJ

這與原始值相似，但絕對(duì)不同。這是因?yàn)镴WT不是單個(gè)base64編碼的字符串。標(biāo)頭和聲明部分是分開(kāi)編碼的，去掉了任何填充信息(由一個(gè)或兩個(gè)等于號(hào)表示)。

在JWT實(shí)現(xiàn)中有一些缺陷，盡管大多數(shù)缺陷比較少見(jiàn)。 對(duì)這些缺陷的利用包括篡改JWT并重新進(jìn)行編碼。雖然這可以手動(dòng)完成，但JSON Web Token Attacker能更容易完成這個(gè)過(guò)程。我們只需從請(qǐng)求中復(fù)制值，然后切換到該插件添加的Burp中的JOSEPH選項(xiàng)卡。接下來(lái)，打開(kāi)Manual子選項(xiàng)卡，并將值粘貼到輸入框中。然后點(diǎn)擊加載按鈕。

之后會(huì)顯示一個(gè)攻擊選擇的下拉框界面。 這里有兩種攻擊方式: 密鑰混淆（Key Confusion）和簽名排除（Signature Exclusion）。雖然對(duì)這些攻擊的深入研究超出了本文要說(shuō)明的范圍，但我會(huì)給出一個(gè)簡(jiǎn)介的總結(jié)，就是這兩種攻擊中的任何一種都會(huì)將頭部的alg值更改為不同的算法;要么將其切換為None值(表示不需要簽名)，要么將其從不對(duì)稱(chēng)加密切換到對(duì)稱(chēng)加密，這樣我們就可以用公鑰生成有效的簽名。其中任何一種方式的安全性的影響是，加密簽名通常是保證令牌完整性的唯一方法。如果攻擊者能夠破解該簽名，則可以修改該令牌，使其具有攻擊者想要的任何聲明。在這個(gè)示例中，這可能意味著攻擊者會(huì)更改用戶ID獲取其他賬戶的會(huì)話并使用該帳戶。

讓我們來(lái)看一下“簽名排除”攻擊方式的操作步驟，并逐步完成基本的手動(dòng)攻擊:

1. 加載輸入

2. 選擇簽名排除

3. 加載

4. 選擇一個(gè)有效載荷，這些是None的變體.

5. 更新

6. 獲取生成的值并將其用于Repeater。如果你從一個(gè)有效的JWT作為攻擊的開(kāi)始，并且篡改的版本被接受了，那么你的攻擊就成功了。之后你就可以繼續(xù)篡改聲明部分了。

密鑰混淆的實(shí)際用法與簽名排除幾乎是一樣的，只是你需要提供公鑰并對(duì)其進(jìn)行轉(zhuǎn)換。 通常的做法是簽名算法選擇 RS256，并且公鑰可用于驗(yàn)證簽名。

另一個(gè)你可能已經(jīng)注意到的事情是，Burp中的代理歷史現(xiàn)在有高亮顯示的功能和一個(gè)新的上下文菜單。

這是一個(gè)用于半自動(dòng)攻擊的插件。 我個(gè)人不喜歡這樣使用這個(gè)插件，部分原因是因?yàn)槲野l(fā)現(xiàn)它有時(shí)會(huì)變得混亂并且生成格式錯(cuò)誤的請(qǐng)求，還有一部分原因是因?yàn)槲蚁矚g嚴(yán)格控制我發(fā)送的流量。另外，對(duì)于實(shí)現(xiàn)JWT失效黑名單的系統(tǒng)的一個(gè)罕見(jiàn)的情況是，格式不正確的令牌會(huì)將會(huì)話列入黑名單。

盡管如此，即使是手動(dòng)攻擊模式也極大地簡(jiǎn)化了生成修改過(guò)的JWT的過(guò)程。 這使得這種方法經(jīng)常成為API測(cè)試的有用工具。我發(fā)現(xiàn)，產(chǎn)生這些漏洞利用的實(shí)現(xiàn)方式似乎并不常見(jiàn)，但是考慮到它們的嚴(yán)重性，應(yīng)該始終對(duì)這些漏洞進(jìn)行測(cè)試。

自動(dòng)化（Autorize）

在API中可能會(huì)出現(xiàn)各種授權(quán)問(wèn)題。除非API是完全公開(kāi)的，否則你至少擁有經(jīng)過(guò)身份驗(yàn)證的訪問(wèn)權(quán)限和未經(jīng)過(guò)身份驗(yàn)證的訪問(wèn)權(quán)限。 如果存在某個(gè)特定用戶擁有的資源或數(shù)據(jù)的概念，那么驗(yàn)證一個(gè)經(jīng)過(guò)身份驗(yàn)證的用戶不能訪問(wèn)他們不擁有的任何資源是非常有意義的。有些API還具有多個(gè)垂直級(jí)別的訪問(wèn)權(quán)限，特別是在有組織概念的情況下。一個(gè)用戶可能比另一個(gè)用戶有權(quán)訪問(wèn)更多的數(shù)據(jù)或功能。同樣，這取決于測(cè)試人員來(lái)確認(rèn)是否強(qiáng)制執(zhí)行了這種權(quán)限配置。最后，在多租戶系統(tǒng)中(例如，每個(gè)客戶機(jī)組織都有自己獨(dú)立的空間) ，租戶之間的數(shù)據(jù)或訪問(wèn)泄漏是最大的安全問(wèn)題之一。

對(duì)于所有這些情況，通用的測(cè)試策略是將資源和功能映射到具有正確權(quán)限的用戶。 然后，我們用不同的訪問(wèn)令牌或會(huì)話重新發(fā)出相同的請(qǐng)求，并比較我們的訪問(wèn)結(jié)果。當(dāng)權(quán)限模型具有任何真正的復(fù)雜性時(shí)，這個(gè)驗(yàn)證過(guò)程可能會(huì)非常耗時(shí)。自動(dòng)化可以顯著提高測(cè)試效率。讓我們從導(dǎo)航到Burp中的Autorize選項(xiàng)卡作為開(kāi)始，這樣我們就可以完成基礎(chǔ)設(shè)置。

1. 在切換經(jīng)過(guò)身份驗(yàn)證的上下文時(shí),我們要替換的標(biāo)頭有一個(gè)大文本框。這可以包括Cookie 和任何其他請(qǐng)求標(biāo)頭,它們要像在正常請(qǐng)求中一樣進(jìn)行設(shè)置。

2. 對(duì)于cookies，你可以點(diǎn)擊“從最后一個(gè)請(qǐng)求獲取 cookie ”的按鈕來(lái)自動(dòng)填充該文本框。

3. 高亮顯示的按鈕“Autorize is…” 用于切換插件的開(kāi)和關(guān)。 當(dāng)關(guān)閉時(shí)，自動(dòng)化將什么也不做。 當(dāng)啟動(dòng)時(shí)，命中 proxy* 的傳入請(qǐng)求將使用你提供的標(biāo)頭或 cookie 進(jìn)行替換并重新發(fā)出請(qǐng)求，同時(shí)省略這些標(biāo)頭或 cookie。

* 界面底部的攔截過(guò)濾器選項(xiàng)卡可用于確定包含哪些請(qǐng)求。

現(xiàn)在已經(jīng)設(shè)置好了 Autorize，你可以通過(guò) Postman 發(fā)出新的請(qǐng)求，并注意左側(cè)的 Autorize 區(qū)域會(huì)被填充。

我的示例 API 恰好具有相同的響應(yīng)，從顯示響應(yīng)長(zhǎng)度的三個(gè)數(shù)字列(分別為74和6)可以看出這一點(diǎn)。 第一個(gè)是對(duì)未修改請(qǐng)求的響應(yīng)，第二個(gè)是替換了令牌的請(qǐng)求，第三個(gè)是未經(jīng)過(guò)身份驗(yàn)證的響應(yīng)。 剩下的兩列用交通信號(hào)燈一樣的顏色表示強(qiáng)制執(zhí)行。 圖中的黃色部分代表的是一種不確定的響應(yīng)，而紅色和綠色的部分分別用于表示授權(quán)是否得到強(qiáng)制執(zhí)行或執(zhí)行成功。

現(xiàn)在，可以使用底部的"未經(jīng)過(guò)身份驗(yàn)證的請(qǐng)求探測(cè)器"和"強(qiáng)制請(qǐng)求探測(cè)器"選項(xiàng)卡來(lái)調(diào)整認(rèn)證何時(shí)生效。 這能夠讓你根據(jù)你對(duì) API 行為的理解創(chuàng)建匹配條件，并且可以極大地改進(jìn)結(jié)果對(duì)響應(yīng)的解釋。 對(duì)于較大的 API，或者那些你預(yù)期要進(jìn)行多次測(cè)試的 API，這么做當(dāng)然是值得的。 但是，對(duì)于一次性測(cè)試，我通常不對(duì)此進(jìn)行調(diào)優(yōu)，而是手動(dòng)檢查響應(yīng)或長(zhǎng)度不一致的情況。

可以使用Autorize UI右側(cè)的選項(xiàng)卡(類(lèi)似于Burp中的典型請(qǐng)求和響應(yīng)選項(xiàng)卡)來(lái)檢查修改過(guò)的和未經(jīng)身份驗(yàn)證的請(qǐng)求和響應(yīng)。這對(duì)于研究請(qǐng)求之間為什么存在差異、API做了什么以及對(duì)服務(wù)端來(lái)說(shuō)是否是正確的請(qǐng)求至關(guān)重要。

關(guān)于如何使用Postman更好的進(jìn)行API滲透測(cè)試就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

當(dāng)前題目：如何使用Postman更好的進(jìn)行API滲透測(cè)試
URL標(biāo)題：http://muchs.cn/article12/pjjhgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、搜索引擎優(yōu)化、做網(wǎng)站、網(wǎng)站收錄、網(wǎng)站導(dǎo)航、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)