利用Jmeter測試CSRF令牌驗證的Web API

標籤：save   bubuko   選項   manage   開發   listener   地址欄   獲得   width   

事情的起因是最近收到的一批測試需求，要測試公司HR系統的介面效能。這個是需要測試的介面列表：

所有的介面請求，都基於登入驗證成功，否則將無法獲得正確的應答。

首先想到的是在瀏覽器上捕捉請求。開啟Chrome瀏覽器，調出開發人員工具列，在地址欄輸入登入模組的地址，訪問登入頁面：

 

輸入帳號和密碼，錄製登入過程；然後定位到開發工具的Network頁面，找到登入的事務。如：

注意右下方的Form Data，這是登入POST方法提交的三個參數，我們需要捕捉的就是_csrf的那個動態令牌。

通過在網上的一番尋找和本地實驗，成功的完成指令碼的調試。

以下是整個過程：

 首先啟動Jmeter UI，建立一個線程組；然後添加一個HTTP請求，取名UserLogin – Open，意在獲得首次開啟登入頁面的CSRF Token。

 

方法使用GET，而實際的登入提交將為POST；這裡並不是實際登入，不用在意。

這裡一定要勾選【跟隨重新導向】，包括之後建立的HTTP請求，都勾選此選項。

請求參數部分，填寫使用者名稱和密碼。由於現在還不能擷取CSRF Token，此時登入並不會成功，但目的不在於登入，而在獲得CSRF Token的內容。

 

完成後，建立一個【後置處理器 - Regex提取器】，這裡抽取登入頁面響應報文中的CSRF Token。內容如：

 

Apply to選項：選中僅應用於主Sample。

這裡需要注意的是“要檢查的響應欄位”，在網上查到的指導都是“訊息頭”，但在本人的測試中，從訊息頭中未能擷取CSRF Token的資訊；因此要設定在“主體”。

引用名稱：可以隨便寫；

Regex：也就是希望提取的內容，格式需要從應答報文中去找。這裡可以參考LoadRunner的關聯的寫法（左邊際、右邊際、Regex匹配的規則）。

實在沒有頭緒的朋友，可以從【察看結果樹】的應答報文中找到，如：

 

模版：$1$，表示取第一次的值；也只有一個；

預設值：隨意，預設為空白。

 

接下來，再建立一個HTTP請求，這次是實現真正的登入請求。

建立第二個HTTP請求，取名UserLogin – POST；因為登入的方法為POST，和前一個進行區分：

 

這次需要把登入提交的三個參數都填上，CSRF Token需要引用上一步從【Regex提取器中擷取】的，寫法是： ${token} 。

完成後，理論上我們就可以運行登入的指令碼了；但是別急，還需要添加一個HTTP Cookie管理器。

我們先看看沒有HTTP Cookie管理器的情況：

 

兩處CSRF Token內容不一致，說明被當成兩次不相關的訪問。

再看看第二個HTTP請求提交的資訊，此處的CSRF Token的內容已經和第一個應答報文一樣了，說明我們前面的努力是正確的；可是為何還是沒有登陸成功呢？

 

稍微想一想就能理解了，伺服器端判斷兩次請求是否來自同一個用戶端，不止一個CSRF Token，還有別的，比如會話ID。

我們翻回瀏覽器的開發人員工具的頁面看看：

 

Cookie中顯然有三個參數，可以預料每次提交的請求，這三個參數都是動態取值；

而要保持會話過程中始終一致，我們需要在JMeter指令碼裡添加HTTP Cookie管理器：

 

添加以後也不需要設定什麼項目，保持最初狀態就夠用了。

補充一下，為了確保HTTP Cookie管理器生效，需要修改jmeter\bin目錄下的jmeter.properties。

找到選項CookieManager.save.cookies，將值修改為true，並刪除句首的 # 號，讓配置生效。

完成修改後，需要重啟JMeter。

重啟之後，我們再執行一次看看結果：

 

對比前一次的執行結果，UserLogin – POST的響應資料發生了變化，顯示的標題是【我的工作台】，這是登入成功的重要標誌；

而且兩次HTTP請求獲得的CSRF Token內容相同，登入操作完美成功。

後面就是添加其他業務API 的請求了，由雩都是GET方式，很容易完成指令碼的編寫。

完成後，添加彙總報告和監控的Backend Listener就齊活了。

 

比如，我們查看一下這個使用者的考勤記錄：

 

執行一遍看看響應報文：

 

 

和期望的一樣，登入之後，再訪問其他功能的API 也能獲得正確的應答。

指令碼編寫工作基本完成了。

利用Jmeter測試CSRF令牌驗證的Web API