在實際的練習中，我們發現如果對Burpsuite中的cookie管理機制有一個大致了解的話，會更有利於實驗的進行，同時在實際的滲透測試中學會使用Burpsuite進行cookie自動化處理也是一項應該具備的能力。
但是搜索了相關方面的文章，發現完整性不佳，於是筆者決定結合官方文檔詳細介紹下Burpsuite的會話管理機制，也作為訪問控制和越權漏洞這一實驗環節的序章。
功能介紹
官方文檔URL：
https://portswigger.net/burp/documentation/desktop/options/sessions
簡單的說Burpsuite會話管理模塊包含這幾個功能：
- Session handling rules：用於設置一系列會話處理規則以對請求中的cookie進行操作
- Session handling tracer：查看Burpsuite所發出請求中哪些受到了會話處理機制的更改
- Cookie jar：Burpsuite存儲的訪問web站點時發出的所有cookie
- Macros：用於預定義一系列請求操作
01會話處理所面臨的挑戰
在執行任何類型的Web應用程序測試時，您可能會遇到與會話處理和狀態相關的挑戰。例如：
- 應用程序可以出於防御或其他原因終止用於測試的會話，以此導致再會話恢復之前所有后續請求都是無效的；
- 有些功能模塊需要隨每個請求提交一個不斷變更的token值(用於阻止請求偽造攻擊)；
- 有些功能可能需要在進行測試請求之前發出一系列其他請求，以使應用程序進入合適的狀態。
這些問題可能會在執行自動化測試任務時出現，例如進行fuzzing或掃描時，也可能在手動測試時出現。
Burpsuite的會話處理機制包含了一系列在所有這些情況下提供幫助的特性，允許您繼續進行手動和自動化測試，而Burpsuite會在后台為您處理各種問題。
02Session handling rules 會話處理規則
新版位置：Project Option->Sessions->Session handling rules
舊版位置：Option->Session
Burpsuite允許您定義一組會話處理規則，讓您可以非常細粒度地控制Burpsuite如何對應用程序的會話機制及相關功能進行操作。
每個規則都包含一個scope(規則適用范圍)和action(規則動作)。對於Burpsuite發出的每個請求，它將確定哪些已定義的規則屬於該請求的作用域，並按順序執行這些規則的所有操作(除非條件檢查操作確定不應該對該請求應用進一步操作)。
每個規則的scope可以根據所處理請求的下列特征來進行定義:
- 發出請求的Burpsuite tools；
- 請求的URL；
- 請求所包含的參數名。
每條規則可執行一個或多個action，例如：
- 從 Burpsuite 的 cookie jar中更新cookie值；
- 驗證當前會話；
- 運行宏（預定義的請求序列）。
通過創建具有不同scope和acion的多個規則，您可以定義行為層次結構使得Burpsuite可以對各種不同的應用程序和功能執行不同操作。例如，在一個特定的測試中，您可以定義以下規則：
- 對於所有的請求，從Burpsuite 的 cookie jar中添加cookie；
- 對於特定域的請求，驗證該應用程序的當前會話是否仍處於活動狀態，如果不是，則重新運行宏登錄到該應用程序，並使用生成的會話令牌更新cookie jar；
- 對於包含csrftoken參數的特定URL的請求，首先運行一個宏來獲得一個有效的csrftoken值，然后附加到后續請求中。
03Session handling tracer 會話處理跟蹤
將Burpsuite的會話處理功能應用到實際應用程序的特性所需要的配置通常很復雜，而且很容易出錯。您可以使用會話處理跟蹤程序來進行故障排除。
跟蹤程序顯示由會話處理功能處理的每個請求(即至少應用了一個會話規則的請求)的清單。對於每個已處理的請求，跟蹤程序顯示執行的規則和操作的順序，以及在順序中的每個步驟中對當前請求所做的更改。
注意，會話處理跟蹤程序對所有受影響的HTTP請求施加處理和存儲開銷。因此應該只在解決會話處理規則問題時使用跟蹤程序，一般不用運行。
04Cookie jar Cookie罐子
Burpsuite維護一個cookie jar，用於存儲您訪問Web站點時發出的所有cookie，所有Burpsuite工具共享cookie jar。
您可以配置cookie jar應該監視哪些工具以更新cookie。默認情況下，cookie jar會根據來自Proxy和Spider的流量進行更新。Burpsuite監聽所配置模塊中接收到的響應，並更新任何新設置的cookie。
對於Proxy模塊，還會檢查來自瀏覽器的傳入請求，這對於應用程序之前設置了瀏覽器中存在的持久cookie，並且正確處理會話需要該cookie時會非常有用。讓Burpsuite根據Proxy的請求更新它的cookie jar意味着所有必要的cookie將被添加到cookie jar中，即使應用程序在您當前的訪問期間沒有更新該cookie值。
點擊Open cookie jar您還可以查看cookie jar的內容並進行手動編輯。
cookie jar可以被Session handling rules和Macro用於自動更新發送請求的cookie值。
cookie jar遵循cookie的域和路徑范圍，在某種程度上模仿Internet Explorer對cookie處理規范的解釋。
05Macros 宏
宏是一個或多個請求的預定義序列，您可以在會話處理規則中使用宏來執行各種任務，宏的典型用例包括：
- 獲取應用程序的頁面(例如用戶的主頁)以檢查當前會話是否仍然有效；
- 執行登錄以獲得一個新的有效會話令牌；
- 獲取令牌或Nonce（在密碼學中Nonce是一個只被使用一次的任意或非重復的隨機數值）作為另一個請求的參數；
- 當在執行一個具有多步驟的fuzzing或掃描過程時，執行必要的先行請求，以使應用程序能夠正確接收測試請求；
- 在一個多步驟流程中，發出“攻擊”請求后，完成流程的其余步驟以確認正在執行的動作，或從該流程處獲得結果或錯誤消息。
除了基本的請求序列外，每個宏還包括一些關於如何處理序列中的cookie和參數的重要配置，以及項之間的任何相互依賴關系。
06Burpsuite內部處理cookie時的細節問題
Burpsuite的會話處理功能與Burpsuite的其他功能在一些重要方面的交互：
1、有一個默認的會話處理規則，它使用Burpsuite 的 cookie jar中的cookie更新Scanner發出的請求，除非Scanner在管理自己的會話(在爬行和爬行驅動的審計期間)。如果這不是您需要的行為，您應該在執行任何掃描之前禁用默認的會話處理規則。
2、當會話處理規則在請求發出前修改請求時(例如，為了更新cookie或其他參數)，為了清晰起見，Burpsuite的一些工具將顯示最終更新的請求，這適用於Intruder、Repeater和Spider工具。在Scanner的issue報告中仍然顯示原始請求，以便在必要時與基本請求進行清楚的比較。要觀察由會話處理程序修改的scan issue的最終請求，您可以將請求發送到Burpsuite Repeater並在那里發送它(如果您為Repeater啟用了與 Scanner相同的會話處理規則)。
3、當Scanner或Intruder發出的請求中包含有cookie或其他參數時，該請求不會受到會話管理機制的影響，以避免干擾正在執行的測試。例如，如果您正在使用Intruder對一個請求中的所有參數進行模糊測試，並且您已經配置了一個會話處理規則來更新該請求中的sessid cookie，那么使用Intruder處理其他參數時，sessid cookie將被更新，但當對Intruder中的sessid cookie參數本身進行操作時時，Burpsuite將發送Intruder中的有效負載作為sessid值，而會話處理規則不會對其產生影響。
實際應用
一個比較簡單的例子就是在我們使用Burpsuite的目錄掃描工具Discover content（位於右鍵->Engagement tools->Discover content）時，首先我們來看看Burpsuite默認的會話處理規則，一般只這樣一條默認規則。
點擊Edit查看具體配置，可以看到其Scope范圍僅僅只有Scanner這一模塊。
也就是說我們平常使用Discover content這一功能時，Burpsuite並不會自動幫助我們將已有cookie添加到請求中，以此導致使用這一目錄探查功能時返回一系列4XX錯誤，並使得最終站點地圖收錄不全。
所以我們需要設置規則以開啟這一cookie添加功能（當然也可以直接編輯原規則勾選Target，Discover content歸屬於Target scope）。
新建一條規則，選擇action為use cookie jar。
切換到Scope選項卡，僅勾選Target，並選擇all URLs。
點擊OK就完成了規則的配置，同樣在其他地方也可以根據需要進行具體配置，關鍵是要理解Burpsuite內部的會話管理機制。
今天的文章分享，小伙伴們看懂了嗎？