若希望從更早前了解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的有效載荷，并不會更新它，因為它是正常的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/442812.html
標籤：其他