如何使用Postman更好的進行API滲透測試

這篇文章將為大家詳細講解有關如何使用Postman更好的進行API滲透測試，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

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

Postman 就是這樣一個工具，它在開發者中已經流行了很多年。 在我們進入如何設置它的主題之前，我們先來快速介紹一下這個工具是什么以及可以做什么。 Postman 是一個商業桌面應用程序，可用于 Windows、 Mac OS 和 Linux。 它的大部分功能是免費的，也有付費的功能，比如提供協作和文檔功能。 與滲透測試人員相比，這些特性對開發人員更有意義。 它用于管理測試各種 API 調用的 HTTP 請求集.合，以及包含變量的環境。 它并不能替代你的代理(如：Burp，ZAP，Mitmproxy 等等) ，但是實際上彌補了瀏覽器和客戶端應用程序層缺失的功能。 對于這款工具主要的替代方案是開源工具 Insomnia 和高級 REST 客戶端，商業產品 SoapUI，或建立在 Swagger/Swagger UI 或 curl 的自定義工具。

設置 Postman

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

在第一次啟動 Postman 時，你會看到一個屏幕，提示你創建一個帳戶，注冊谷歌，或者用現有的憑證進行登錄。 然而， Postman 并不需要一個帳戶來執行后續的使用。

登錄的帳戶用于協作/同步/等; 這些是付費的功能。正如我前面提到的，這幾個功能對于開發人員來說很棒，但對你來說，可能并不關心。 事實上，如果你通常需要對你的客戶端機械能保密，就像我們在 Secure Ideas 所做的事情，那么你可能明確地不希望將你的項目同步到另一個第三方服務器。

如果你低頭看窗口的底部，你會看到一些淺灰色的文字，上面寫著跳過登錄，直接把我帶到了應用程序界面。 點擊這個灰色的鏈接，你將移動到下一個屏幕——一個提示你創建東西的對話框。

有幾個部分你不會在這里使用到，所以讓我們看看你真正關心的三個功能:

• 集.合（Collection）——一個你可以用請求填充的通用容器。 它還可以作為一些配置選擇的頂級對象，比如身份驗證規則(Authentication rules) ，我們稍后將對其進行詳細說明。

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

• 環境（Environment） ——這里可以保存你希望在某個地方控制并發出跨請求甚至跨集.合所使用的變量。

使用 Postman 的基本知識

是時候創建我們的第一個 Postman 集.合并發出 HTTP 請求。

左上角的 New 按鈕通常用于創建集.合和請求。 讓我們首先創建一個集.合。 這有點像一個單獨的應用程序。 你將用于對相關請求進行分組。

集.合還可以作為具有身份驗證指令的頂級項，這些身份驗證指令將對單個請求進行繼承。 現在，只要給它起個名字，然后點擊創建按鈕就行了。 這里，我起的名字是“測試集.合”。

默認情況下，你已經打開了一個未命名的請求選項卡。 讓我們來看看 UI 的這一部分。

1. 活動選項卡

2. 此請求的名稱。 這只是一些描述性的名稱，你可以寫也可以不寫。

3. HTTP 方法。 這個下拉控件允許你更改此請求的方法。

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

5. 用于設置請求的各種屬性的選項卡式界面，包括參數、HTTP 頭、HTTP 主體等。

6. 發送按鈕。 這實際上是將請求提交到指定的 URL。

7. 保存按鈕。 第一次單擊此選項時，你需要指定你的集.合，因為請求必須屬于某個集.合。

我在 HTTP://localhost:4000上設置了一個示例目標，所以我將從填寫這個請求并保存到我的某個集.合作為開始。我將發出一個 POST 請求，到 HTTP://localhost:4000/legacy/auth ，沒有任何參數(這是一個測試 API。 任何人都可以通過身份驗證)。 當我點擊保存按鈕時，我將命名請求并為它選擇一個集.合，如下圖所示：

然后單擊"保存到測試集.合"(根據你的集.合名稱進行調整)按鈕來保存我的請求。 現在，單擊 Send 按鈕將發出請求。 然后我將看到響應填充在窗口的下窗格中，如下圖所示：

1. 選項卡界面有 Body , Cookies , Headers 及測試結果。 我們還沒有編寫任何測試，但是請注意圖中標出的響應返回的cookie ，headers。

2. 實際響應的 HTTP Body 位于較大的文本窗格中。

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

4. 關于響應的衡量標準包括 HTTP狀態碼、響應時間和響應大小。

關于 Cookies 的一個旁注

現在，如果我們使用 Postman 重新發出請求，我們將注意到一個重要的事情: 之前在響應中設置的 cookie 會被自動包含。 它模仿了瀏覽器通常為你做的事情。 正如你對瀏覽器的期望一樣，在這個 cookie 范圍內發出的任何請求，Postman 都將自動包含該 cookie。

如果你想移除某個 cookie 該怎么做呢？ 這很簡單。 在 Postman 的發送按鈕下面，有一個類似鏈接的按鈕，上面寫著 Cookies。 點擊這個按鈕，會打開一個對話框，在那里你可以刪除或編輯任何你需要的 cookies。

這就是基于 cookie 的 API。 但是讓我們面對現實: 現在我們常見的 API 都會使用無記名令牌（Bearer Token）這比使用 Cookies 更為普遍。

為什么要設置代理？

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

設置 Burp Suite

對 Burp 的實際介紹超出了這篇文章的范圍。 如果你正在閱讀這篇文章，很可能你已經對它很熟悉了

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

同時檢查 Proxy 下的 Intercept 選項卡并驗證 Intercept 是否關閉。

在 Postman 中配置 Burp 代理

Postman 是代理感知的，這意味著我們要將它指向我們的中間人代理，也就是 Burp Suite。 我們將通過點擊右上角的扳手圖標(1)打開設置對話框，然后點擊下拉菜單上的設置選項(2)。 這會打開一個比較大的設置對話框，在頂部有不同類別設置的標簽。 找到"代理"選項卡并單擊進行設置。

打開 Postman 設置面板

在這個標簽頁上有三件事可以做:

1. 打開全局代理配置開關（Global Proxy Configuration）

2. 關閉"使用系統代理（Use System Proxy）"開關

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

默認的代理接口是127.0.0.1，端口是8080，這里假設你的 Postman 和你的 Burp Suite 是在同一臺機器上運行的。 如果你想使用不同的端口，你需要在這里指定它，并確保它被設置為與 Burp 中的代理接口一樣。

現在你可以代理流量了，還有一個問題需要考慮。 如今，大多數公共 API 都使用了 SSL/TLS 。 這是一件非常好的事情，但它也意味著當 Burp 作為代理中間人在處理 Postman 的 API 請求和響應時，你會遇到證書錯誤的問題，除非你的系統已經信任了 Burp 的證書頒發機構。 解決這個問題有兩個方法:

1. 你可以關閉 Postman 中的證書驗證。 在 General 設置選項卡下面有一個 SSL 認證驗證選項。 設置為 關掉（Off），將使 Postman 忽略任何證書問題，包括 Burp Suite 的 PortSwigger CA 。

2. 你可以將你的Burp Suite CA 設置到系統信任存儲。 具體的設置細節和平臺有關系。
   
   

驗證代理是否正常工作

用 Postman 發出一些請求。 在 Burp 的 Proxy 選項卡上檢查你的 HTTP 歷史記錄。

在 Burp Suite 中的代理歷史記錄

故障排除

• 你發出的請求存在拖延和超時問題？ 在 Burp 中的代理選項卡上檢查"攔截"是否關閉。 檢查 Postman 中的代理設置是否與 Burp 中的代理接口相匹配。

• Postman 收到了響應，但響應沒有顯示在 Burp 的代理歷史中（等等）？ 打開 Postman 的”設置"界面，檢查"全局代理配置"是否打開。 確保你沒有激活 Burp 歷史記錄的過濾器來過濾掉你所有的請求。 如果沒有捕獲過濾范圍外的流量，模擬還要確保是否在 Burp 中設置了范圍（scope）。

現在我們已經做好了基本的工具鏈設置。

集.合變量

Postman 中的變量幾乎可以用于請求中的任何字段。 語法是在它們的兩邊使用兩層花括號。有幾個地方我可以使用變量定義它們。 如果它們是靜態的，也許我會將它們設置為集.合變量。 例如，我一直使用 http://localhost:4000作為我的測試主機。 如果我將測試 API 的端口從4000改為4001，我不希望一個個編輯每個請求的 URL。接下來我介紹一下我們該如何將它移動到一個集.合變量中。首先，在菜單側欄中打開"集.合"列表中編輯該集.合的對話框。 我可以單擊… 按鈕或者右鍵單擊集.合名稱。這兩種操作，我們會得到相同的上下文菜單，然后選擇編輯（Edit）。

這將打開一個編輯集.合的對話框。 默認視圖包括集.合的名稱和描述的文本框，但是在這兩個字段之間還有一行選項卡。

其中一個標簽叫做變量（Variables）。這就是我們想要的，點擊這個標簽會打開另一個對話框，用于編輯變量。

Postman 集.合變量編輯界面

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

現在是時候修改我的請求，并引用該變量，而不是使用硬編碼的主機名和端口。

Postman中的請求，將URL更改為指向一個變量

我只是簡單地用占位符替換了每個 URL 中對應的部分:  {{API_host}}，把鼠標懸停在占位符上可以展開這個變量，會顯示變量值和范圍。 這里有一些顏色編碼也可以幫助我們。 當變量有效時，文本會變成橙色，但是如果我輸入一個無效的變量名，文本將變成紅色。

我仍然需要對每個請求進行一次更新，讓它們使用某個變量。 但是在將來，如果我改變了端口，或者如果我切換到了 HTTPS，或者如果我將我的測試 API 部署到一個完全不同的主機上; 那么我就可以回到集.合變量那里并更新變量的值，我的所有請求都會相應地發生改變。

現在，集.合變量對于相對靜態的字段以及不會經常發生改變的字段是很適合的，但是如果我在一個多租戶的解決方案中測試多個環境和部署，甚至多個租戶呢？ 我可能會使用相同的請求集.合，但是使用不同的變量集.合。 那么在這種情下環境變量就可以處理這個問題。

環境變量（Environment Variables）

你可能已經注意到了窗口右上角的界面。 讓我們打開看看:

在 Postman 中的環境變量界面

1. 環境選擇器下拉菜單。可以選擇一個環境。

2. 快速查看按鈕，點擊后可以查看你的環境中設置的內容。

3. 管理環境按鈕，這里是真正進行編輯環境的地方。

首先，我們需要點擊管理環境按鈕。 這會打開一個較大但空白的對話框，底部有一個 Add 按鈕。 點擊這個添加按鈕。

你會看到另一個對話框。 這一個看起來幾乎和集.合變量對話框一樣，除了它有一個名字。

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

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

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

現在這些額外的變量可以像上面的 API_host 變量一樣進行訪問: {{bearer_token}} 和 {{user_id}}

路由參數

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

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

我也可以把我的變量直接寫到URL中，但在我看來，這種方式更干凈。

無記名令牌（Bearer Tokens）

想象一下這樣一個場景: 你發出某種類型的授權請求，它用一個 bearer token 進行響應，然后你需要在所有其他請求中使用該令牌。 這樣做的手動方式可能只是發出驗證請求，然后從響應中復制并粘貼令牌到另外一個環境變量。 所有其他的請求都可以使用這個環境變量。

這樣也可以正常發出請求，如果你有一個短期的令牌，那么這種做法可能會很痛苦。對于這個問題，有一個更優雅的解決方案。想想下面的響應:

我們已經發出了請求，并且收到了一個包含令牌的 JSON 響應。 現在，我想用自動化的方式使用新的bearer token來更新我的環境變量。 在請求界面上，有幾個標簽可以做到。 最右邊的一個叫做測試。 這主要用于自動檢查響應，以確定 API 是否失效，就像單元測試一樣。 但是我們可以通過一些 JavaScript 語句來達到我們的目的。

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

我們可以看到當前值已經被自動更新。 這是第一步——我現在將值存儲在一個我可以輕松引用的地方，但是它不會將Bearer token 這個令牌放入我的請求中。 我有兩個方法。 第一個方法是，如果打開請求的 Authorization 選項卡，我們可以從類型下拉列表中設置一個Bearer token，并將其指向我的變量。

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

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

偶爾，我會遇到一些應用程序，需要從響應中包含的XML或HTML主體中提取一些值。 在這種情況下，內置的xml2Json 函數有助于解析響應內容。

使用 xml2Json 將 HTML 主體整合到 JSON 對象中

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

設置 Jython

其中的一些擴展需要在 Burp Suite中設置Python環境，而Burp Suite在默認情況下是不配置Python環境信息的。如果你已經配置過了，那么你可以繼續下面的操作。如果沒有配置過，你可以打開 Extender-Options 并設置Jython的獨立JAR的位置。如果你需要這個下載jar包，你可以從jython.org上找到。

設置好路徑后，導航到 BApp Store 選項卡，就可以開始下載我們將要使用的擴展插件了。我想重點說明的兩個插件是JSON Web Token Attacker和Autorize。

現在讓我們更詳細地看看這兩個插件。

JSON Web Token Attacker

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

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

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

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9LnsidXNlcmlkIjoxLCJ0b2tlbmlkIjoiZmFjMTU5MzktZGUzMC00ODFkLTlkMTMtNmFlODllY2Q3MzcwIiwiaWF0IjoxNTUyNDQ0NjM3LCJleHAiOjE1NTI0NDgyM04zMC7colISpedlNHItBvijbS0TmYWzzIFAAOmykTIWurMtDzVJ

這與原始值相似，但絕對不同。這是因為JWT不是單個base64編碼的字符串。標頭和聲明部分是分開編碼的，去掉了任何填充信息(由一個或兩個等于號表示)。

在JWT實現中有一些缺陷，盡管大多數缺陷比較少見。 對這些缺陷的利用包括篡改JWT并重新進行編碼。雖然這可以手動完成，但JSON Web Token Attacker能更容易完成這個過程。我們只需從請求中復制值，然后切換到該插件添加的Burp中的JOSEPH選項卡。接下來，打開Manual子選項卡，并將值粘貼到輸入框中。然后點擊加載按鈕。

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

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

1. 加載輸入

2. 選擇簽名排除

3. 加載

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

5. 更新

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

密鑰混淆的實際用法與簽名排除幾乎是一樣的，只是你需要提供公鑰并對其進行轉換。 通常的做法是簽名算法選擇 RS256，并且公鑰可用于驗證簽名。

另一個你可能已經注意到的事情是，Burp中的代理歷史現在有高亮顯示的功能和一個新的上下文菜單。

這是一個用于半自動攻擊的插件。 我個人不喜歡這樣使用這個插件，部分原因是因為我發現它有時會變得混亂并且生成格式錯誤的請求，還有一部分原因是因為我喜歡嚴格控制我發送的流量。另外，對于實現JWT失效黑名單的系統的一個罕見的情況是，格式不正確的令牌會將會話列入黑名單。

盡管如此，即使是手動攻擊模式也極大地簡化了生成修改過的JWT的過程。 這使得這種方法經常成為API測試的有用工具。我發現，產生這些漏洞利用的實現方式似乎并不常見，但是考慮到它們的嚴重性，應該始終對這些漏洞進行測試。

自動化（Autorize）

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

對于所有這些情況，通用的測試策略是將資源和功能映射到具有正確權限的用戶。 然后，我們用不同的訪問令牌或會話重新發出相同的請求，并比較我們的訪問結果。當權限模型具有任何真正的復雜性時，這個驗證過程可能會非常耗時。自動化可以顯著提高測試效率。讓我們從導航到Burp中的Autorize選項卡作為開始，這樣我們就可以完成基礎設置。

1. 在切換經過身份驗證的上下文時,我們要替換的標頭有一個大文本框。這可以包括Cookie 和任何其他請求標頭,它們要像在正常請求中一樣進行設置。

2. 對于cookies，你可以點擊“從最后一個請求獲取 cookie ”的按鈕來自動填充該文本框。

3. 高亮顯示的按鈕“Autorize is…” 用于切換插件的開和關。 當關閉時，自動化將什么也不做。 當啟動時，命中 proxy* 的傳入請求將使用你提供的標頭或 cookie 進行替換并重新發出請求，同時省略這些標頭或 cookie。

* 界面底部的攔截過濾器選項卡可用于確定包含哪些請求。

現在已經設置好了 Autorize，你可以通過 Postman 發出新的請求，并注意左側的 Autorize 區域會被填充。

我的示例 API 恰好具有相同的響應，從顯示響應長度的三個數字列(分別為74和6)可以看出這一點。 第一個是對未修改請求的響應，第二個是替換了令牌的請求，第三個是未經過身份驗證的響應。 剩下的兩列用交通信號燈一樣的顏色表示強制執行。 圖中的黃色部分代表的是一種不確定的響應，而紅色和綠色的部分分別用于表示授權是否得到強制執行或執行成功。

現在，可以使用底部的"未經過身份驗證的請求探測器"和"強制請求探測器"選項卡來調整認證何時生效。 這能夠讓你根據你對 API 行為的理解創建匹配條件，并且可以極大地改進結果對響應的解釋。 對于較大的 API，或者那些你預期要進行多次測試的 API，這么做當然是值得的。 但是，對于一次性測試，我通常不對此進行調優，而是手動檢查響應或長度不一致的情況。

可以使用Autorize UI右側的選項卡(類似于Burp中的典型請求和響應選項卡)來檢查修改過的和未經身份驗證的請求和響應。這對于研究請求之間為什么存在差異、API做了什么以及對服務端來說是否是正確的請求至關重要。

關于如何使用Postman更好的進行API滲透測試就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。