若希望從更早前了解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的有效載荷，並不會更新它，因為它是正常的。