若希望從更早前瞭解BurpSuite的介紹，請訪問第三篇（滲透測試之BurpSuite工具的使用介紹（三））：https://www.cnblogs.com/zhaoyunxiang/p/16000725.html

七、Burp Repeater（重放）介紹：

使用 Burp Repeater(Using Burp Repeater)，Burp Repeater是一個手動修改並補發個別 HTTP請求，並分析他們的響應的工具。它最大的用途就是和其他 Burp Suite工具結合起來。你可以從目標站點地圖，從 Burp Proxy瀏覽記錄，或者從 Burp Intruder攻擊結果上的請求，傳送到 Repeater上，並手動調整這個請求來微調對漏洞的探測或攻擊。

當你從其他工具上傳送請求到 Repeater上時，這些請求會得到它自己的選項。每個選項有自己的請求和響應視窗，以及自己的記錄。面板的上半部允許你配置目標的主機和埠，以及請求的細節。你可以手動地完成這些資訊，然而當你從其他 Burp Suite工具上傳送一個請求時，相關的細節都會為你完成了：

當你配置好一個請求，單擊”go”按鈕傳送它到伺服器。響應會在顯示視窗的下半部顯示出來。對請求和響應二者，許多訊息檢視是可用的：

raw —這顯示純文字格式的訊息。在文字面板的底部有一個搜尋和加亮的功能，可以用來快速地定位出訊息裡的感興趣的字串，如出錯訊息。搜尋欄左邊的彈出項讓你能控制狀況的靈敏度，以及是否使用簡單文字或者十六進位制搜尋。

params—對於包含引數(URL查詢字串，cookie頭，或者訊息體)的請求，這個選項把這些引數分析為名字/值的格式，這就可以簡單地隨他們進行檢視和修改了。

headers—這裡是以名字/值的格式來顯示 HTTP的訊息頭，並且也以原始格式顯示了訊息體。

hex —這裡允許你直接編輯由原始二進位制資料組成的訊息。如果在文字編輯器修改，某種型別的傳輸(如，MIME編碼的瀏覽器請求)包含了可能損壞的二進位制內容。為了修改這類訊息，應該使用十六進位制編輯器。

HTML/XML —對於包含了這些格式內容的響應，這裡提供了一個訊息體的顏色語法格式檢視。

render—對於包含 HTML或者影象內容的響應，這裡會以可見的形式顯示出這些內容，就像顯示在你瀏覽器那樣。

AMF—對於 Action Message Format格式的請求和響應，顯示了一個編碼訊息的檢視樹。如果可編輯，你可以雙擊檢視樹上的單個節點來修改它們的值。

viewstate—對於包含 ASP.NET ViewState引數的請求，這會把 ViewState中的內容進行反序列化，使你能夠檢視任何敏感項包含的資料。也指示了 ViewState MAC項是否可用(也就是 ViewState MAC是否可修改)。

在任何請求和響應上，右擊它們就會產生一個上下文選單，來進行下面的操作：

send to—你可以傳送任何訊息，或者選中的部分訊息到其他 Burp Suite工具上，來執行進一步操作或分析。

find references— [僅限專業版]你可以使用這個功能在所有的 Burp工具上來搜尋連線到當前項的 HTTP響應。

discover content— [僅限專業版]你可以使用這個功能來發現那些不是連線到由瀏覽或網路爬蟲發現的內容的內容和功能。

schedule task— [僅限專業版]你可以使用這個功能來建立一些在定義的時間和間隔內自動執行的任務。

change request mothod—針對請求，你可以在 POST和 GET之間自動地切換請求方法，並使用相關的請求引數穩定地載入這些請求。這個選項可以用來以潛在的惡意請求來快速地測試到應用程式的極限引數的位置。

change body encoding—針對請求，你可以在應用程式/X—www—form URL編碼和multipart/form-data之間進行切換任意訊息體的編碼方式。

copy URL—這個功能是把當前的完整 URL複製到貼上板上。

copy to file —這個功能允許你選擇一個檔案，然後把訊息的內容複製到這個檔案裡。這對二進位制內容很方便，然而通過貼上板會產生一些問題。在選中的文字上進行復制操作，如果什麼也沒選中，則複製整個訊息。

paste from file—這個功能允許你選擇一個檔案，然後把檔案裡的內容貼上到訊息裡。這對二進位制內容很方便，然而通過貼上板會產生一些問題。貼上會替換選中的文字，如果什麼也沒選中，則在游標的位置插入。

save item—這個功能讓你指定一個檔案用來儲存 XML格式的選中的請求和響應，這裡包含了所有相關的元資料，如響應長度，HTTP狀態碼和 MIME型別。

convert selection —這些功能讓你能夠以各種方案快速地對選中的文字進行編碼解碼。URL-encode as you type—如果這個選項被開啟，則像&和=這樣的字元會被你輸入的相等的 URL編碼替換。

你可以使用<和>按鈕來後退和前進瀏覽當前選項的請求記錄，如果需要，可以修改任何請求。

1.選項：

“repeater”選單控制 Burp Repeater的各方面的行為。你可以建立一個新的空白項，刪除一個現有項，或者恢復一個選項的標題來幫助你繼續你的工作。如果” update Content-Length header”框被選中，Burp Repeater使用一個特殊請求的 HTTP主體長度的正確值，來更新每個請求的訊息頭(如果需要可以新增訊息頭)的內容長度。這個功能在手動修改 HTTP主體時是很有用的，這可能會改變它的長度。HTTP規範和大多數的web伺服器都需要使用訊息頭的內容長度指定HTTP主體長度的正確值。如果沒指定正確值，則目標伺服器就會返回一個錯誤，也可能返回一個未完成的請求，或者無限期地等待接收請求的下一資料。

如果” unpack gzip / deflate”框被選中，Burp Repeater在顯示之前會把 gzip / deflate格式壓縮的內容解壓。重定向設定控制著 Burp Repeater是否會跟蹤 HTTP重定向(那些有 3XX狀態碼的和包含新 URL的本機訊息頭)。

下面的選項是可用的：

1.Nerver— Repeater不會跟蹤任何重定向。

2.On-site-only— Repeater只會跟蹤同一 web站點的重定向。如，在本地請求中使用的有相同的主機，埠，協議 URL。

3.In-scope only— Repeater會只跟蹤那些在 Suite-wide目標範圍(定義在目標選項卡)內的 URL。

4.Always— Repeater會跟蹤任意 URL。你應該小心地使用這個選項— web應用程式

偶爾會以重定向的方式轉發你的請求引數到第三方 web站點，於是通過跟蹤這個重定向你不經意間的就攻擊了一個不打算攻擊的應用程式。當 Repeater接收到一個配置來跟蹤的重定向時，它會請求這個重定向(如果需要，最多跟蹤 10個重定向，不再多了，這樣為了避免無限地迴圈)。在一個重定向面板上顯示了從重定向 URL得到的響應。訊息的狀態指示出是否跟蹤了一個重定向，以及有多少重定向。當應用程式對多種輸入都返回一個 3XX響應時，這個跟蹤重定向的選項就有用了，因為當請求重定向目標時，會返回應用程式處理你請求的許多感興趣的特徵。例如，當探測常規漏洞時，應用程式會頻繁地返回指向錯誤頁面的重定向—這個頁面會包含錯誤本質的有用資訊，這可被用來診斷像 SQL注入的問題。如果選中” process cookies in redirects”選項，如果跟蹤了一個到相同域名的重定向，則要重新提交任何設定有 3XX響應的 cookie。

注意當 Burp Repeater接收到一個不是配置為自動跟蹤的重定向響應，會在 Repeater介面的頂部顯示一個” follow redirect”按鈕。這允許你檢視後，手動跟蹤這個重定向。這個功能是用來穿過重定向序列裡的每個請求和響應。如果這些選項被設定在上面的”process cookies”配置裡，則用這些手動的重定向來處理這些新 cookie。

“action”子選單包含了和右擊請求或響應面板的可用的一樣的項。

八、Burp 的Session Handler介紹

會話處理的挑戰(Session handling challenges)，當對應用程式進行模糊測試或掃描時，會常常遇到一些問題：

1.應用程式會因為防守或其它原因終止了進行測試的會話，並且其餘的測試連續也是無效的了。

2.有些應用程式改變每個請求必須提供的節點(例如，來阻止請求欺騙攻擊)。

3.有些功能在測試這個請求之前，需要一系列的請求，才能讓應用程式進入一個接收測試。

1.試請求的合適狀態：

當你進行手動測試時，所有的這些問題都能產生，並且手動解決這些問題常常顯得無聊，這會降低你對下面測試的慾望。

Burp包含了一系列的功能來幫你解決這些情況，讓你繼續你的手動的和自動的測試，Burp會在後臺為照看這些問題。所有的會話相關的配置都可以在主選項卡里的會話選項卡里找到。

Burp的 cookie容器(Burp's cookie jar)

Burp儲存了一個追蹤 cookie的 cookie容器，這個容器可以用在許多應用程式會話中。這個 cookie容器被所有的 Burp工具共享。響應中設定的 cookie會儲存在 cookie容器中，這些 cookie會被自動地新增到即將傳送的請求裡。

所有的這些都是可配置的，例如，你可以為 Proxy和 Spider接收到的 cookie來更新 cookie容器，以及 Burp會自動地把 cookie新增到 Scanner和 Repeater傳送的請求裡。在主選項卡里的會話選項卡顯示了 cookie容器的配置：

如上面顯示的，預設的 cookie容器是依靠 Proxy和 Spider的傳輸進行更新的。你可以檢視 cookie容器的內容並按照自己的意願來手動編輯 cookie：

除了 Proxy其他的所有工具，都要檢查 HTTP響應以確認新 cookie。除了 Proxy，從瀏覽器進入的請求也被檢查。當有個應用程式設定了一個永久 cookie，這個 cookie出現你的瀏覽器裡，並且還需要這個 cookie來適當處理你的會話時，這個會有用了。Burp依據通過代理的請求來更新它的 cookie容器，這就意味著，即使在你訪問時應用程式不更新 cookie的值，所有需要的 cookie都會被新增到 cookie容器裡。

Burp的 cookie容器遵循 cookie的域範圍，用一種方式來模仿 Internet Explorer的解釋cookie的處理規範。不需遵循路徑範圍。

2.會話處理規則：

Burp讓你定義了一個會話處理規則列表，這讓能完全控制著 Burp是怎樣來處理應用程式的會話處理機制和相關的功能。在主選項卡里的會話選項卡來配置這些規則：

每個規則包含了一個範圍(規則應用的物件)和操作(規則做什麼)。對於 Burp要傳送的每一個請求，它決定要使用哪一個規則來處理請求，並且按順序執行每個規則的動作 (除非條件檢查操作確定該請求不需要進一步的處理)。

每個規則定義的範圍，是根據處理請求的以下特徵而設定的：

1.處理請求的 Burp工具。

2.請求的 URL。

3.請求裡的引數名。

每個規則執行的一個或多個動作。實施以下動作：

1.新增會話處理 cookie容器中的 cookie。

2.設定一個特定的 cookie或引數值。

3.檢查當前會話是否可用，並有條件地在結果上執行一些子操作。

4.為恢復瀏覽器的會話提示使用者。

5.執行一個巨集。

6.執行一個 POST請求巨集(這來處理當前請求，並執行下一個巨集)。

所有的這些操作都是高度可配置的，可以以任意的方式結合起來處理任何會話處理機制。能執行任意巨集(定義在請求佇列的)，並能更新結果上的指定 cookie和引數值，允許你通過部分自動掃描或 Intruder攻擊來自動重新登入到一個應用程式。恢復瀏覽器會話提示讓你和登入機制一起工作，這些機制有輸入物理令牌的一個數字或者解決一個 CAPTCHA型別的難題。

通過建立多個不同範圍和操作的規則，你可以為 Burp應用到不同應用程式和功能的行為定義一個層次結構。例如，在一個特殊的測試上你可以定義一下規則：

1.對所有的請求，新增 Burp的 cookie容器裡的 cookie。

2.對一個特定域的請求，驗證那個應用程式的當前會話是否存活，如果不是，執行一個巨集重新登入到應用程式，並且使用結果裡的會話令牌更新 cookie容器。

3.對特定的包含__CSRF令牌引數 URL的請求，首先執行一個包含__CSRF令牌值的巨集，然後在提出請求時使用。

怎樣配置 Burp來完成這些的細節內容將在接下來的部分給大家介紹；

3.巨集：

Burp的會話處理功能的關鍵部分就是執行巨集的能力，和定義在會話處理的規則一樣。巨集是一個單個或多個請求的預定義序列。典型的使用巨集的情況有：

1.獲取一個檢查當前會話是否存活的一個應用程式頁面(如使用者的主頁面)。

2.執行一個包含新的存活會話的登入。

3.包含一個用在其他請求裡的令牌或隨機數。

4.當在多步處理過程掃描或模糊測試一個請求時，執行必須的先前請求，來讓應用程式進入一個接收目標請求的狀態。

5.在一個多步處理過程中，攻擊請求發出後，完成剩下的處理步驟，以確認要執行的操作，或者從處理結果獲取結果或出錯資訊。

使用瀏覽器記錄下巨集。當定義一個巨集，Burp會顯示一個 Proxy理論記錄的檢視，從這裡你可以為巨集來選擇要使用的請求。你可以從先前產生的請求裡選擇，或者重新記錄這個巨集並且從歷史記錄選擇這個項。

當你記錄下這個巨集，巨集編輯器在巨集裡顯示出這個項的細節，你可以預覽，以及按照需要來配置：

和基礎的請求序列一樣，每個巨集都包含了一些重要配置資訊，怎樣處理序列裡的項，以及項之間的相互依存關係：

對於巨集裡的每個項，可進行以下配置：

1.是否應該把會話處理 cookie容器裡的 cookie新增到請求裡。

2.從響應裡接收的 cookie是否應該被新增到會話處理的 cookie容器裡。

3.對於請求裡的每個引數，是否應該使用一個預設值，或者使用一個巨集以前的響應裡的派生值。

4.在更新的引數值裡，關鍵字元是否進行 URL編碼。

在一些多階段處理過程中，從一個先前的響應派生一個引數值的能力通常是很有用的，並且在這種情況下，應用程式能更好地利用逆 CSRF令牌。當定義了一個新的巨集，Burp會通過確認由先前響應決定值的引數(構造欄位值，重定向目標，查詢連線裡的字串，等等)，來自動嘗試查詢和這一類的關係。你可以在使用巨集之前，簡單地預覽並編輯 Burp使用的巨集配置。下面，可以隔離測試配置的巨集，以及預覽完整的請求 /響應序列，來檢查是不是你需要的功能。

4.使用示例：

讓我們觀察一個只能通過認證會話使用的應用程式功能，以及使用後面的令牌來抵禦CSRF攻擊。你想測試那些基於輸入像 XXS和 SQL注入的漏洞的功能。執行自動測試這個功能，會面臨兩個挑戰：(a)確保使用的會話存活(b)獲取每個請求裡使用的可行令牌。Burp的會話處理功能能處理這兩個挑戰。

要做到這樣，我要定義一些會話處理規則。這些規則將應用到我們要測試的功能發出的請求上，使用功能的工具是 Intruder,Scanner和 Repeater：

1.通過請求應用程式裡的使用者登入介面來檢查當前會話是否有效，然後檢查響應以確認使用者是否登入進來。

2.如果沒登入進來，重新登入以獲得一個有效會話。

3.請求我們將要測試的包含提交的頁面。這個格式在一個隱藏的模組裡包含了我們需要的逆 CSRF令牌。

4.對我們使用逆 CSRF令牌的值來測試的功能，更新請求。

在大多數情況下，我們需要使用 Burp自己的會話處理的 cookie容器，所以在第一條規則裡，我們就告訴 Burp把 cookie容器裡的 cookie新增到每個請求裡。這樣，實際上，也就是 Scanner和 Spider工具的預設規則，於是我們就只修改 Intruder和 Repeater工具的預設規則即可。這規則執行一個操作，在下面顯示：

規則的定義的範圍來包含相關的工具，並對所有 URL適用：

下一步，我需要檢查目標應用程式上的當前使用者會話是否可用。假設我想要把這些規則應用到目標應用程式的所有請求上，我可以把它定義在整個應用程式域的範圍內：

然後，我們新增一個合適的描述以及一個”check session is valid”型別的操作：

這裡打開了這型別操作的編輯器，它裡面包含了許多配置項：

選項的第一步設定是確定了 Burp使用哪一個請求來驗證當前會話。這些選項是：

1.傳送當前正在處理的實際請求。如果應用程式會對有常規響應簽名的會話外請求作出迴應，如一個登入重定向時，選上這個選項是明智的。

2.執行一個巨集，來發送一個或多個請求。如果是為了確認會話是否有效，這就是一個理想的選項，你需要請求一些標準的項，如使用者的主頁。這個選項也會是最好，在需要使用進一步規則來修改當前處理的請求—例如(像在當前情況下)，更新請求裡的逆 CSRF令牌。如果選項是為了執行一個選中的巨集，你需要進一步選擇是否要對每一個請求或者其中的 N個請求。如果應用程式對未預料的輸入會積極地終止響應裡的會話，建議你驗證每次會話；否則你可以只定期驗證會話來加快速度。在當前的例項中，我要執行一個巨集來獲取應用程式裡的使用者登入介面，以檢測他們的會話是否有效。要這樣做，我們需要單擊上一截圖裡的”new”按鈕，來定義自己的巨集。這裡打開了巨集記錄器，讓我們來選擇希望包含在巨集裡的請求。當前狀況下，我們只需要選擇使用者登入頁面裡的 GET請求：

選項的第二部設定是”check session is valid”操作控制 Burp怎樣檢查巨集裡的響應來確定會話是否有效。許多選項是可用的，下面列出了當前情況下我們需要的配置：

在這裡，我們使用 cookie容器裡的 cookie配置了 Burp進行更新請求，並且在會話有效時，把使用者重新登入到應用程式。為完成需要的配置，我們需要定義一個延伸規則來處理在我們要測試功能裡逆 CSRF令牌。我們要測試請求像這樣：

POST /auth/4/NewUserStep2.ashx HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: mdsec.net
Content-Length: 137
Cookie: SessionId=39DD9F0CB979BFB431005524A4010244
realname=testuser&username=testuser&userrole=user&password=letmein1&confirmpasswor
d=letmein1&nonce=938549246127349541173

為確保這個功能正確地處理了我們的請求，需要每個請求提供的隨機數有效。在應用程式裡的產生上面請求的格式的隱藏區域提供了這個隨機數值。因此，我們需要執行一個巨集來獲取包含這個格式的頁面，並使用隨機引數值來更新當前請求。我們使用一個有”run macro”型別的操作來新增一個延伸規則，並像下面這樣來配置它：

在上面的配置裡，我們指定了 Burp應該執行一個新巨集，來獲取包含逆 CSRF令牌的格式，和從巨集響應中獲取隨機引數，以及在請求裡更新。另外，我們可以選擇”update all parameters”選項，Burp會自動地嘗試請求裡的引數和在巨集響應指定的值進行匹配。在規則範圍內，明顯地需要定義在比整個應用程式域更窄的範圍。例如，我們可以把這個規則只定義在上面請求裡 URL上。如果應用程式只能使用一些位置上的逆 CSRF令牌。然而，在一些應用程式上，許多功能都使用令牌，在這種情況下，令牌會獲取到不止一種功能。我們可以定義一個使用所有域的規則，但僅限於包含一個指定引數名字的請求。在這種方法下，無論何時嚮應用程式提交的請求中都會包含一個逆 CSRF令牌，這個規則執行後，Burp會獲取一個新的有效令牌來用在請求上。

這個配置，有它的 3個會話處理規則和 3個巨集，在 Burp主介面裡就像這樣：

你可以通過在應用程式上登出，向 Burp Repeater傳送已認證的有令牌保護的請求，來測試配置的執行狀況以及確認它是否執行了需要的操作。這些請求可能會花費比平常長的時間才能返回，因為 Burp在幕後提交了許多其他請求，以驗證你的會話，如果需要可以再次登入，並獲取請求使用的令牌。

如果你發現你的規則不按你打算的方式工作，你可以使用 session handling tracer來解決這個問題。一旦你為會話處理規則正確地執行而感到高興時，你就可以把這些請求傳送到 Burp Intruder或者 Scanner，來以正常地方式執行你的自動化測試。

5.會話處理跟蹤器

配置需要把 Burp的會話處理規則應用到現實世界裡的應用程式功能上，這往往是很複雜的，並且很容易產生錯誤。Burp提供了一個跟蹤功能，來排除會話處理配置的故障。當Burp把會話處理規則應用到一個請求上時，這裡顯示了執行的所有步驟，讓你清楚地看到怎樣來處理和更新請求的。你可以通過 options / sessions / view sessions tracer來開啟會話處理跟蹤器：

九、Burp工具的整合

關於會話處理功能對一些其他 Burp的功能影響，需要注意以下幾點：

1.這裡有一個預設的會話處理規則來更新那些由 Scanner和 Spider用 Burp的 cookie容器裡 cookie產生的所有請求。這確保了所有 spidering和掃描的請求都是在會話裡產生的，並且還使用你的瀏覽器來維持了一個有效的會話。這也意味著，在主動掃描佇列裡的項，是從一個穩定檔案里加載過來的，並會在你當前的會話裡掃描，而不是儲存狀態檔案的那個啟用的會話。如果這不是你想要的行為，在執行掃描之前，你應該使這個預設會話處理規則不可用。

2.如遇到會話處理規則在請求傳送之前，就把它修改了(例如，更新一個 cookie或其它引數)，一些 Burp工具，為了清晰，會顯示出最終更新的請求。這使用在 Intruder,Repeater和 Spider工具。在 Scanner報告裡顯示傳送的請求的同時，還繼續顯示原來的請求，在需要的地方，就能方便清楚地和基礎請求進行對比。為了觀察一次掃描發出的最後一個請求，和會話處理器一樣，你可以先把請求傳送到 Burp Repeater，然後在傳送它。

3.當 Scanner或者 Intruder提交一個請求，這請求操縱了一個由會話處理操作影響 cookie或引數時，這個操作不會應用到那個請求上，這是為了避免干擾正在進行的測試。例如，如果你正在使用 Intruder對請求裡的所有引數進行模糊測試，並且你已經配置了一個會話處理規則來更新請求裡的”sessid”cookie，當 Intruder對其他引數進行模糊測試時，這個”sessid”cookie就會被更新。當 Intruder對”sessid”cookie自身進行模糊測試時，Burp會把”sessid”的值作為 Intruder的有效載荷，並不會更新它，因為它是正常的。