- Burp Suite 安裝和環境配置
- Burp Suite代理和瀏覽器設置
- 如何使用Burp Suite 代理
- SSL和Proxy高級選項
- 如何使用Burp Target
- 如何使用Burp Spider
- 如何使用Burp Scanner
- 如何使用Burp Intruder
- 如何使用Burp Repeater
- 如何使用Burp Sequencer
- 如何使用Burp Decoder
- 如何使用Burp Comparer
第二部分 Burp Suite 高級
- 數據查找、提取以及正則表達式的使用
- Burp Suite拓展功能的使用
- Burp Suite應用商店插件的使用
- 如何編寫自己的Burp Suite插件
第三部分 Burp Suite 綜合使用
- 使用Burp Suite測試Web Services服務
- 使用Burp, Sqlmap進行自動化SQL注入滲透測試
- 使用Burp、PhantomJS進行XSS檢測
- 使用Burp 、Radamsa進行瀏覽器fuzzing
- 使用Burp 、Android Killer進行安卓app滲透測試
第一章 Burp Suite 安裝和環境配置
Burp Suite是一個集成化的滲透測試工具,它集合了多種滲透測試組件,使我們自動化地或手工地能更好的完成對web應用的滲透測試和攻擊。在滲透測試中,我們使用Burp Suite將使得測試工作變得更加容易和方便,即使在不需要嫻熟的技巧的情況下,只有我們熟悉Burp Suite的使用,也使得滲透測試工作變得輕松和高效。
Burp Suite是由Java語言編寫而成,而Java自身的跨平台性,使得軟件的學習和使用更加方便。Burp Suite不像其他的自動化測試工具,它需要你手工的去配置一些參數,觸發一些自動化流程,然后它才會開始工作。
Burp Suite可執行程序是java文件類型的jar文件,免費版的可以從免費版下載地址進行下載。免費版的Burp Suite會有許多限制,很多的高級工具無法使用,如果您想使用更多的高級功能,需要付費購買專業版。專業版與免費版的主要區別有
- Burp Scanner
- 工作空間的保存和恢復
- 拓展工具,如Target Analyzer, Content Discovery和 Task Scheduler
本章主要講述Burp Suite的基本配置,包含如下內容:
- 如何從命令行啟動Burp Suite
- 如何設置JVM內存 大小
- IPv6問題調試
如何從命令行啟動Burp Suite
Burp Suite是一個無需安裝軟件,下載完成后,直接從命令行啟用即可。但Burp Suite是用Java語言開發的,運行時依賴於JRE,需要提前Java可運行環境。如果沒有配置Java環境或者不知道如何配置的童鞋請參考win7電腦上的Java環境配置
配置完Java環境之后,首先驗證Java配置是否正確,如果輸入java -version 出現下圖的結果,證明配置正確且已完成。
這時,你只要在cmd里執行java -jar /your_burpsuite_path/burpSuite.jar即可啟動Burp Suite,或者,你將Burp Suite的jar放入class_path目錄下,直接執行java -jar burpSuite.jar也可以啟動。
注意:your_burpsuite_path為你Burp Suite所在路徑,burpSuite.jar文件名必須跟你下載的jar文件名稱一致
如何設置JVM內存 大小
如果Java可運行環境配置正確的話,當你雙擊burpSuite.jar即可啟動軟件,這時,Burp Suite自己會自動分配最大的可用內存,具體實際分配了多少內存,默認一般為64M。當我們在滲透測試過程,如果有成千上萬個請求通過Burp Suite,這時就可能會導致Burp Suite因內存不足而崩潰,從而會丟失滲透測試過程中的相關數據,這是我們不希望看到的。因此,當我們啟動Burp Suite時,通常會指定它使用的內存大小。
一般來說,我們通常會分配2G的內存供Burp Suite使用,如果你的電腦內存足夠,可以分配4G;如果你的電腦內存足夠小,你也可以分配128M。當你給Burp Suite分配足夠多的內存時,它能做的工作也會更多。指定Burp Suite占用內存大小的具體配置方法是在啟動腳本里添加如下命令行參數:
假設啟動腳本的名稱為burp_suite_start.bat,則該bat腳本的內容為
java -jar -Xmx2048M /your_burpsuite_path/burpsuite.jar
其中參數-Xmx指定JVM可用的最大內存,單位可以是M,也可以是G,如果是G為單位的話,則腳本內容為:
java -jar -Xmx2G /your_burpsuite_path/burpsuite.jar
更多關於JVM性能調優的知識請閱讀 Oracle JVM Tuning
IPv6問題調試
Burp Suite是不支持IPv6地址進行數據通信的,這時在cmd控制台里就會拋出如下異常
java.net.SocketException: Permission denied
同時,瀏覽器訪問時,也會出現異常
Burp proxy error: Permission denied: connect
當出現如上問題時,我們需要修改啟動腳本,添加對IPv4的指定后,重啟Burp Suite即可。
java -jar -Xmx2048M -Djava.net.preferIPv4Stack=true /your_burpsuite_path/burpsuite.jar
通過 -Djava.net.preferIPv4Stack=true參數的設置,告訴Java運行環境,使用IPv4協議棧進行數據通信,IPv6協議將會被禁止使用。
這個錯誤最常見於64位的windows操作系統上,使用了32位的JDK
第二章 Burp Suite代理和瀏覽器設置
Burp Suite代理工具是以攔截代理的方式,攔截所有通過代理的網絡流量,如客戶端的請求數據、服務器端的返回信息等。Burp Suite主要攔截http和https協議的流量,通過攔截,Burp Suite以中間人的方式,可以對客戶端請求數據、服務端返回做各種處理,以達到安全評估測試的目的。
在日常工作中,我們最常用的web客戶端就是的web瀏覽器,我們可以通過代理的設置,做到對web瀏覽器的流量攔截,並對經過Burp Suite代理的流量數據進行處理。
下面我們就分別看看IE、Firefox、Google Chrome下是如何配置Burp Suite代理的。
IE設置
當Burp Suite 啟動之后,默認分配的代理地址和端口是127.0.0.1 :8080,我們可以從Burp Suite的proxy選項卡的options上查看。如圖:
現在,我們通過如下步驟的設置即可完成IE通過Burp Suite 代理的相關配置。
- 啟動IE瀏覽器
- 點擊【工具】菜單,選擇【Internet】選項
- 打開【連接】選項卡,點擊【局域網設置】,進行代理設置。
- 在代理服務器設置的地址輸入框中填寫127.0.0.1,端口填寫8080,點擊【確定】,完成代理服務器的設置。
- 這時,IE的設置已經完成,你可以訪問 http://burp 將會看到Burp Suite的歡迎界面。
FireFox設置
與IE的設置類似,在FireFox中,我們也要進行一些參數設置,才能將FireFox瀏覽器的通信流量,通過Burp Suite代理進行傳輸。詳細的步驟如下:
- 啟動FireFox瀏覽器,點擊【工具】菜單,點擊【選項】。
- 在新打開的about:preferences#advanced窗口中,依次點擊【高級】-【網絡】,我們將會看到FireFox連接網絡的設置選項。
- 點擊【設置】,在彈出的【連接設置】對話框中,找到“http代理”,填寫127.0.0.1,端口填寫8080,最后點擊【確認】保存參數設置,完成FireFox的代理配置。
當然,FireFox瀏覽器中,可以添加FireFox的擴展組件,對代理服務器進行管理。例如FireX Proxy、Proxy Swither都是很好用的組件,感興趣的讀者可以自己下載試用一下。
Google Chrome設置
Google Chrome使用Burp Suite作為代理服務器的配置步驟如下:
- 啟動Google Chrome瀏覽器,在地址欄輸入chrome://settings/,回車后即顯示Google Chrome瀏覽器的配置界面
- 點擊底部的【顯示高級設置】,將顯示Google Chrome瀏覽器的高級設置。
- 當然,你也可以直接在搜索框中輸入“代理”,回車后將自動定位到代理服務器設置功能。
- 點擊【更改代理服務器設置】,windows系統下將會彈出IE瀏覽器的代理設置,此時,按照IE瀏覽器的設置步驟,完成代理服務器的配置即可。
除了上述的三種常用的瀏覽器外,還有Safari瀏覽器也有不少的用戶在使用,其代理配置請點擊閱讀進行查看。
第三章 如何使用Burp Suite代理
Burp Proxy 是Burp Suite以用戶驅動測試流程功能的核心,通過代理模式,可以讓我們攔截、查看、修改所有在客戶端和服務端之間傳輸的數據。
本章主要講述以下內容:
- Burp Proxy基本使用
- 數據攔截與控制
- 可選項配置Options
- 歷史記錄History
Burp Proxy基本使用
通過上一章的學習,我們對Burp Suite代理模式和瀏覽器代理設置有了基本的了解。Burp Proxy的使用是一個循序漸進的過程,剛開始使用時,可能並不能很快就獲取你所期望的結果,慢慢地當你熟悉了它的功能和使用方法,你就可以用它很好地對一個產品系統做安全能力評估。
一般使用Burp Proxy時,大體涉及環節如下:
- 首先,確認JRE已經安裝好,Burp Suite可以啟動並正常運行,且已經完成瀏覽器的代理服務器配置。
- 打開Proxy功能中的Intercept選項卡,確認攔截功能為“Interception is on”狀態,如果顯示為“Intercept is off”則點擊它,打開攔截功能。
- 打開瀏覽器,輸入你需要訪問的URL(以http://baike.baidu.com/為例)並回車,這時你將會看到數據流量經過Burp Proxy並暫停,直到你點擊【Forward】,才會繼續傳輸下去。如果你點擊了【Drop】,則這次通過的數據將會被丟失,不再繼續處理。
- 當我們點擊【Forward】之后,我們將看到這次請求返回的所有數據。
- 當Burp Suite攔截的客戶端和服務器交互之后,我們可以在Burp Suite的消息分析選項卡中查看這次請求的實體內容、消息頭、請求參數等信息。消息分析選項視圖主要包括以下四項:
- Raw 這是視圖主要顯示web請求的raw格式,包含請求地址、http協議版本、主機頭、瀏覽器信息、Accept可接受的內容類型、字符集、編碼方式、cookie等。你可以通過手工修改這些信息,對服務器端進行滲透測試。
- params 這個視圖主要顯示客戶端請求的參數信息、包括GET或者POST請求的參數、Cookie參數。滲透人員可以通過修改這些請求參數來完成對服務器端的滲透測試。
- headers 這個視圖顯示的信息和Raw的信息類似,只不過在這個視圖中,展示得更直觀、友好。
- Hex 這個視圖顯示Raw的二進制內容,你可以通過hex編輯器對請求的內容進行修改。
默認情況下,Burp Proxy只攔截請求的消息,普通文件請求如css、js、圖片是不會被攔截的,你可以修改默認的攔截選項來攔截這些靜態文件,當然,你也可以通過修改攔截的作用域、參數或者服務器端返回的關鍵字來控制Burp Proxy的消息攔截,這些在后面的章節中我們會進一步的學習。
所有流經Burp Proxy的消息,都會在http history記錄下來,我們可以通過歷史選項卡,查看傳輸的數據內容,對交互的數據進行測試和驗證。同時,對於攔截到的消息和歷史消息,都可以通過右擊彈出菜單,發送到Burp的其他組件,如Spider、Scanner、Repeater、Intruder、Sequencer、Decoder、Comparer、Extender,進行進一步的測試。如下圖所示:
數據攔截與控制
Burp Proxy的攔截功能主要由Intercept選項卡中的Forward、Drop、Interception is on/off、Action、Comment 以及Highlight構成,它們的功能分別是:
Forward的功能是當你查看過消息或者重新編輯過消息之后,點擊此按鈕,將發送消息至服務器端。
Drop的功能是你想丟失當前攔截的消息,不再forward到服務器端。
Interception is on表示攔截功能打開,攔截所有通過Burp Proxy的請求數據;Interception is off表示攔截功能關閉,不再攔截通過Burp Proxy的所有請求數據。
Action的功能是除了將當前請求的消息傳遞到Spider、Scanner、Repeater、Intruder、Sequencer、Decoder、Comparer組件外,還可以做一些請求消息的修改,如改變GET或者POST請求方式、改變請求body的編碼,同時也可以改變請求消息的攔截設置,如不再攔截此主機的消息、不再攔截此IP地址的消息、不再攔截此種文件類型的消息、不再攔截此目錄的消息,也可以指定針對此消息攔截它的服務器端返回消息。
Comment的功能是指對攔截的消息添加備注,在一次滲透測試中,你通常會遇到一連串的請求消息,為了便於區分,在某個關鍵的請求消息上,你可以添加備注信息。
Highlight的功能與Comment功能有點類似,即對當前攔截的消息設置高亮,以便於其他的請求消息相區分。
除了Intercept中可以對通過Proxy的消息進行控制外,在可選項設置選項卡Options中也有很多的功能設置也可以對流經的消息進行控制和處理。
可選項配置Options
當我們打開可選項設置選項卡Options,從界面顯示來看,主要包括以下幾大板塊(涉及https的功能不包含在本章內容里,后面會一章專門敘述):
- 客戶端請求消息攔截
- 服務器端返回消息攔截
- 服務器返回消息修改
- 正則表達式配置
- 其他配置項
客戶端請求消息攔截
客戶端請求消息攔截是指攔截客戶端發送到服務器端消息的相關配置選項,其界面如下:
主要包含攔截規則配置、錯誤消息自動修復、自動更新Content-Length消息頭三個部分。
- 如果intercept request based on the follow rules的checkbox被選中,則攔截所有符合勾選按鈕下方列表中的請求規則的消息都將被攔截,攔截時,對規則的過濾是自上而下進行的。當然,我們可以根據自己的需求,通過【Up】和【Down】按鈕,調節規則所在位置和排序。同時,我們可以點擊【Add】添加一條規則,也可以選中一條規則,通過點擊【Edit】進行編輯、點擊【Remove】進行刪除。當我們點擊【Add】按鈕時,會彈出規則添加的輸入對話框,如下圖:
攔截規則添加時,共包含4個輸入項。Boolean opertor表示當前的規則與其他規則是與的方式(And)還是或的方式(Or)共存;Match type表示匹配類型,此處匹配類型可以基於域名、IP地址、協議、請求方法、URL、文件類型、參數, cookies, 頭部或者內容, 狀態碼, MIME類型, HTML頁面的title等。Match relationship表示此條規則是匹配還是不匹配Match condition輸入的關鍵字。當我們輸入這些信息,點擊【OK】按鈕,則規則即被保存。 - 如果Automatically fix missing的checkbox被選中,則表示在一次消息傳輸中,Burp Suite會自動修復丟失或多余的新行。比如說,一條被修改過的請求消息,如果丟失了頭部結束的空行,Burp Suite會自動添加上;如果一次請求的消息體中,URl編碼參數中包含任何新的換行,Burp Suite將會移除。此項功能在手工修改請求消息時,為了防止錯誤,有很好的保護效果。
- 如果Automatically update Content-Length的checkbox被選中,則當請求的消息被修改后,Content-Length消息頭部也會自動被修改,替換為與之相對應的值。
服務器端返回消息攔截
服務器端返回消息攔截顧名思義是指攔截服務器端返回的消息的相關配置項,其界面如下:
它的功能主要包含intercept response based on the follow rules和Automatically update Content-Length header when the response edited兩個選項,其功能分別與客戶端請求消息攔截中的intercept request based on the follow rules、Automatically update Content-Length header when the request edited相對應,就不在贅述,請參上一節的內容。
服務器返回消息修改
服務器返回消息修改是指自動修改服務器端返回消息的相關設置項。其界面如下:
自上而下,每一個選擇項分別對應的功能是
- 顯示form表單中隱藏字段
- 高亮顯示form表單中隱藏字段
- 使form表單中的disable字段生效,變成可輸入域
- 移除輸入域長度限制
- 移動JavaScript驗證
- 移動所有的JavaScript
- 移除
<object>
標簽 - 轉換https超鏈接為http鏈接
- 移除所有cookie中的安全標志
通過服務器返回消息修改可選擇項的設置,可以方便滲透測試人員在安全評估過程中突破原有的數據限制,更好、更快地檢測服務器端的安全性。
正則表達式配置
此項配置主要用來自動替換請求消息和服務器端返回消息中的某些值和文本,它與前文的規則的不同之處還在於支持正則表達式語言。
當點擊【Add】按鈕時,在彈出的匹配或替換規則輸入對話框中我們可以看到,它可以對請求和返回消息的消息頭,消息體、請求參數名、請求參數值、請求的第一行進行匹配和替換。例如,當我們要替換所有返回消息中的郵箱地址為t0data@burpsuite.com時,可以參考下圖的設置填寫輸入項並保存驗證。
其他配置項
其他配置項主要是雜項設置。其界面如下:
自上而下依次的功能是
指定使用HTTP/1.0協議與服務器進行通信
這項設置用於強制客戶端采用HTTP/1.0協議與服務器進行通信,一般客戶端使用的HTTP協議版本依賴於客戶端瀏覽器,但某些服務器或者應用,必須使用HTTP/1.0協議,此時可勾選此項指定使用HTTP/1.0協議反饋消息給客戶端
目前所有的瀏覽器均支持HTTP/1.0協議和HTTP/1.1協議,強制指定HTTP/1.0協議主要用於顯示瀏覽器的某些方面的特征,比如,阻止HTTP管道攻擊。設置返回消息頭中的“Connection:close”
可用於某些情況下的阻止HTTP管道攻擊。請求消息頭中脫掉Proxy-*
瀏覽器請求消息中,通常會攜帶代理服務器的相關信息,此選項主要用於清除消息頭中的代理服務器信息。解壓請求消息中的壓縮文件
某些應用在與服務器端進行交互時,會壓縮消息體,勾選此選項,則Burp Suite 會自動解壓消息體解壓返回消息中的壓縮文件
大多數瀏覽器支持壓縮的消息體,勾選此選項,則Burp Suite 會自動解壓被服務器端壓縮的消息體允許通過DNS和主機名訪問web接口
即允許通過域名或主機名訪問Burp Suite不在瀏覽器中顯示Burp Suite錯誤
在我們使用Burp Suite時,如果發生了Burp Suite自身的錯誤,會在瀏覽器中顯示,如果勾選了此項,則不會在瀏覽器中顯示此類錯誤。禁用日志到歷史和網站地圖中
此選項的作用是阻止記錄日志到歷史和網站地圖,在某些情況下可能有用,比如說,通過上游服務器進行認證或者做正則表達式替換時,為了降低內存的消耗,減少日志的儲存,你可以勾選此項。攔截功能開始設置
這個選項主要用來配置intercept功能的生效方式,分為總是生效、 總是失效 、從上一次的Burp Suite中恢復設置3種方式。
歷史記錄History
Burp Proxy的歷史記錄由HTTP歷史和WebSockets歷史兩個部分組成。
HTTP歷史界面由篩選過濾器、歷史記錄列表、消息詳情3個部分組成。
當我們在某一條歷史記錄上單擊,會在下方的消息詳解塊顯示此條消息的文本詳細信息。當我們在某條消息上雙擊,則會彈出此條消息的詳細對話框。
我們可以點擊對話框右上方的【Previous】、【Next】按鈕,瀏覽上一條或下一條消息的內容,也可以修改Raw的請求參數,然后執行多種【Action】操作。
歷史消息列表中主要包含請求序列號、請求協議和主機名、請求的方式、URL路徑、請求參數、Cookie、是否用戶編輯過消息、服務器端返回的HTTP狀態碼等信息。通過這些信息,我們可以對一次客戶端與服務器端交互的HTTP消息詳情做出准確的分析,同時,在下方的詳情視圖中,也提供基於正則表達式方式的匹配查找功能,更好的方便滲透測試人員查找消息體中的相關信息。
當我們在做產品系統的安全評估過程中,會在HTTP歷史中保存了大量的日志記錄,為了更友好的消息管理,Burp提供了篩選過濾器功能。當我們點擊HTTP歷史標簽下發的Filter時,將彈出篩選過濾器界面。
按照過濾條件的不同,篩選過濾器划分出7個子板塊,分別是
按照請求類型過濾
你可以選擇僅顯示當前作用域的、僅顯示有服務器端響應的和僅顯示帶有請求參數的消息。當你勾選“僅顯示當前作用域”時,此作用域需要在Burp Target的Scope選項中進行配置,詳細請閱讀Burp Target相關章節。按照MIME類型過濾
你可以控制是否顯示服務器端返回的不同的文件類型的消息,比如只顯示HTML、css或者圖片。此過濾器目前支持HTML、Script、XML、CSS、其他文本、圖片、Flash、二進制文件 8種形式。按照服務器返回的HTTP狀態碼過濾
Burp根據服務器的狀態碼,按照2XX,3XX,4XX,5XX分別進行過濾。比如,如果你只想顯示返回狀態碼為200的請求成功消息,則勾選2XX。按照查找條件過濾
此過濾器是針對服務器端返回的消息內容,與輸入的關鍵字進行匹配,具體的匹配方式,你可以選擇 1.正則表達式 2.大小寫敏感 3.否定查找 3種方式的任何組合,前面兩種匹配方式容易理解,第3種匹配方式是指與關鍵字匹配上的將不再顯示。按照文件類型過濾
通過文件類型在過濾消息列表,這里有兩個選擇可供操作。一是僅僅顯示哪些,另一個是不顯示哪些。如果是僅僅顯示哪些,在show only的輸入框中填寫顯示的文件類型,同樣,如果不顯示哪些文件類型,只要在hide的輸入框中填寫不需要顯示的文件類型即可。按照注解過濾
此過濾器的功能是指,根據每一個消息攔截時候的備注或者是否高亮來作為篩選條件控制哪些消息在歷史列表中顯示。按照監聽端口過濾
此過濾器通常使用於當我們在Proxy Listeners中多個監聽端口時,僅僅顯示某個監聽端口通信的消息,一般情況下,我們很少用到。
現在,我們再看看WebSockets歷史選項的功能,從界面上我們可以看出,WebSockets歷史所提供的功能和選項是HTTP歷史的一個子集,只是因為采用的通信方式的不同,而被獨立出來成為一個專門的視圖。其功能的使用方式與HTTP歷史雷同,此處就不在贅述。
通過本章的學習,你對Burp Suite的代理模式有了更深入的理解,知道了作為中間人的Burp Proxy在消息攔截過程中,可以對請求消息、應答消息做多方面的修改,並可以把消息傳遞給Burp的其他組件做進一步的測試。同時,Burp Proxy的歷史日志功能和多種篩選過濾器讓我們在使用中,能快速地查找需要的數據和關鍵信息,這些,都極大地幫助你提高了工作效率。
第四章 SSL和Proxy高級選項
在前一章,我們已經學習了HTTP消息如何通過Burp Proxy進行攔截和處理,本章我們將繼續學習HTTPS協議消息的攔截和處理。
HTTPS協議是為了數據傳輸安全的需要,在HTTP原有的基礎上,加入了安全套接字層SSL協議,通過CA證書來驗證服務器的身份,並對通信消息進行加密。基於HTTPS協議這些特性,我們在使用Burp Proxy代理時,需要增加更多的設置,才能攔截HTTPS的消息。
本章包含的主要內容有
- CA證書的安裝
- CA證書的卸載
- Proxy監聽設置
- SSL直連和隱形代理設置
我們都知道,在HTTPS通信過程中,一個很重要的介質是CA證書,下面就我們一起來看看Burp Suite中CA證書的安裝。
CA證書的安裝
一般來說,Burp Proxy代理過程中的CA主要分為如下幾個步驟(以win7下IE9為例):
- 首先,根據前三章內容的學習,你已配置好Burp Proxy監聽端口和IE的代理服務器設置。其次,你的IE瀏覽器中沒有安裝過Burp Suite的CA證書,如果已經安裝,請先卸載證書。詳細的卸載方法請參考CA證書的卸載章節。
- 以管理員身份,啟動IE瀏覽器,在地址欄輸入http://burp並回車,進入證書下載頁面
- 點擊上圖所示的證書下載,另存為到本地目錄。
- 點擊瀏覽器上的【工具】菜單,打開【Internet選項】。
- 在彈出的證書對話框中,點擊【內容】-【證書】。
- 在彈出的證書對話框中,選中【受信任的根證書頒發機構】,點擊【導入】。
- 點擊【下一步】,選擇步驟3保存的證書文件,進行下一步操作。
- 指定證書的存儲位置,如圖
- 點擊【下一步】,直至完成。這時,會提示安全警告,點擊【是】,提示導入完成。
- 關閉IE,重啟瀏覽器,CA證書即配置完成。
CA證書的卸載
CA證書的卸載的通常有兩種方式,第一種方式在上一章節CA證書安裝中的第6步,找到需要卸載的證書,點擊【刪除】即可。我們這里主要描述第二種刪除方式,主要是為了解決在第一種方式的基礎上刪除按鈕失效或者證書列表里看不到的證書也一起刪除的方法。
- 首先,我們打開cmd,輸入mmc,或者你在運行輸入框里直接輸入mmc回車,會彈出管理控制台。
- 點擊【文件】菜單,打開【添加/刪除管理單元】
- 找到證書,如下圖1,點擊【添加】按鈕,如下圖2
- 在彈出的對話框中默認選中【我當前的用戶】,點擊【完成】,一直到結束,這是會在控制台跟節點下多了一個證書的節點。
- 打開CA證書所在的位置,選擇刪除即可。
- 這時,你再返回到IE瀏覽器的證書列表里,則不會再看到被刪除的證書了。
除了IE之外,其他的瀏覽器如FireFox、Chrome、Sarifa等都證書的安裝和卸載基本類似,操作時可以以IE的CA證書安裝作為參考。
Proxy監聽設置
當我們啟動Burp Suite時,默認會監聽本地回路地址的8080端口,除此之外,我們也可以在默認監聽的基礎上,根據我們自己的需求,對監聽端口和地址等參數進行自由設置。特別是當我們測試非瀏覽器應用時,無法使用瀏覽器代理的方式去攔截客戶端與服務器端通信的數據流量,這種情況下,我們會使用自己的Proxy監聽設置,而不會使用默認設置。
- Proxy監聽設置
當我們在實際使用中,可能需要同時測試不同的應用程序時,我們可以通過設置不同的代理端口,來區分不同的應用程序,Proxy監聽即提供這樣的功能設置。點擊圖中的【Add】按鈕,會彈出Proxy監聽設置對話框,里面有更豐富的設置,滿足我們不同的測試需求。
Proxy監聽設置主要包含3塊功能:
端口和IP綁定設置Binding
綁定的端口port是指Burp Proxy代理服務監聽的端口,綁定IP地址分僅本地回路、所有接口、指定地址三種模式,在滲透測試中,無論你選擇哪種模式,你需要明白一點,當你選擇的非本地回路IP地址時,同局域網內的其他電腦也可以訪問你的監聽地址。請求處理Request Handling
請求處理主要是用來控制接受到Burp Proxy監聽端口的請求后,如果對請求進行處理的。
其具體配置可分為:端口的轉發、主機名/域名的轉發、強制使用SSL和隱形代理4個部分。當我們配置了端口的轉發時,所有的請求都會被轉發到這個端口上;如果我們配置了主機或域名的轉發,則所有的請求會轉發到指定的主機或域名上。同時,我們可以指定,通過Burp Proxy的消息是否強制使用SSL,如果設置了此項,則請求若是http協議,經Burp proxy代理后將轉換為https協議。隱形代理主要是用於測試富客戶端應用或者是非瀏覽器代理方式的應用,當我們設置了它,訪問這些應用時,將通過非代理的方式,直接連接Burp Proxy的監聽端口。SSL 證書
這些設置控制呈現給SSL客戶端的服務器SSL證書。可以解決使用攔截代理時出現的一些SSL問題:
1.您可以消除您的瀏覽器的SSL警報,並需要建立SSL例外。其中,網頁加載來自其他域的SSL保護的項目,可以確保這些正確的加載到瀏覽器,而不需要為每個域手動接受代理的SSL證書。
2.可以與該拒絕無效的SSL證書連接到服務器胖客戶機應用程序的工作。
它有下列選項可供設置:
- 使用自簽名證書(Use a self-signed certificate ) —— 一個簡單的自簽名SSL證書呈現給您的瀏覽器,它總是會導致SSL警告。
- 生成每個主機的CA簽名證書(Generate CA-signed per-host certificates)—— 這是默認選項。在安裝時,Burp創造了一個獨特的自簽名的證書頒發機構(CA)證書,並將此計算機上使用。當你的瀏覽器發出的SSL連接指定主機,Burp生成該主機的SSL證書,由CA證書簽名。您可以安裝Burp的CA證書作為瀏覽器中的受信任的根,從而使每個主機證書沒有任何警報接受。
- 生成與特定的主機名CA簽發的證書(Generate a CA-signed certificate with a specific hostname)—— -是類似於前面的選項;不同的是,Burp會生成一個主機證書與每一個SSL連接使用,使用指定的主機名。
- 使用自定義證書(Use a custom certificate)—— 此選項可以加載一個特定的證書(在PKCS#12格式)呈現給瀏覽器。如果應用程序使用這需要一個特定的服務器證書(例如,與給定的序列號或證書鏈)的客戶端應該使用這個選項。
SSL直連和隱形代理
SSL直連的設置主要用於指定的目的服務器直接通過SSL連接,而通過這些連接的請求或響應任何細節將在Burp代理攔截視圖或歷史日志中可見。通過SSL連接傳遞可以並不是簡單地消除在客戶機上SSL錯誤的情況下有用。比如說,在執行SSL證書的移動應用。如果應用程序訪問多個域,或使用HTTP和HTTPS連接的混合,然后通過SSL連接到特定的主機問題仍然使您能夠以正常的方式使用Burp的其他方式進行通信。如果啟用自動添加客戶端SSL協商失敗的選項,當客戶端失敗的SSL協議檢測(例如,由於不承認Burp的CA證書),並會自動將相關的服務器添加到SSL直通通過列表中去。其設置界面如下圖所示:
有時候,在攔截富客戶端軟件時,我們通常需要使用隱形代理。富客戶端軟件通常是指運行在瀏覽器之外的客戶端軟件,這就意味着它本身不具有HTTP代理是屬性。當它進行網絡通信時,客戶端將無法使代理感知或者無法由代理進行通信。在Burp中,我們可以使用隱形代理的方式,對通信內容進行代理或攔截,從而對通信的請求和響應消息進行分析。使用隱形代理通常需要做如下設置(以https://example.com為例):
1.配置hosts文件,Windows操作系統下的目錄位置Windows/System32/drivers/etc/hosts,而Linux或者Unix下的目錄為/etc/hosts,添加如下行:
127.0.0.1 example.com
2.第一步設置完成之后,我們需要添加一個新的監聽來運行在HTTP默認的80端口,如果通信流量使用HTTPS協議,則端口為443。
3.如果是HTTPS協議的通信方式,我們需要一個指定域名的CA證書。
4.接着,我們需要把Burp攔截的流量轉發給原始請求的服務器。這需要在Options->Connections->Hostname Resolution 進行設置。因為我們已經告訴了操作系統,example.com的監聽地址在127.0.0.1上,所以我們必須告訴Burp,將example.com的流量轉發到真實的服務器那里去。
5.通過這樣的配置,我們就可以欺騙富客戶端軟件,將流量發送到Burp監聽的端口上,再由Burp將流量轉發給真實的服務器。
第五章 如何使用Burp Target
Burp Target 組件主要包含站點地圖、目標域、Target 工具三部分組成,他們幫助滲透測試人員更好地了解目標應用的整體狀況、當前的工作涉及哪些目標域、分析可能存在的攻擊面等信息,下面我們就分別來看看Burp Target的三個組成部分。
本章的主要內容有:
- 目標域設置 Target Scope
- 站點地圖 Site Map
- Target 工具的使用
目標域設置 Target Scope
Target Scope中作用域的定義比較寬泛,通常來說,當我們對某個產品進行滲透測試時,可以通過域名或者主機名去限制攔截內容,這里域名或主機名就是我們說的作用域;如果我們想限制得更為細粒度化,比如,你只想攔截login目錄下的所有請求,這時我們也可以在此設置,此時,作用域就是目錄。總體來說,Target Scope主要使用於下面幾種場景中:
- 限制站點地圖和Proxy 歷史中的顯示結果
- 告訴Burp Proxy 攔截哪些請求
- Burp Spider抓取哪些內容
- Burp Scanner自動掃描哪些作用域的安全漏洞8在Burp Intruder和Burp Repeater 中指定URL
通過Target Scope 我們能方便地控制Burp 的攔截范圍、操作對象,減少無效的噪音。在Target Scope的設置中,主要包含兩部分功能:允許規則和去除規則。
其中允許規則顧名思義,即包含在此規則列表中的,視為操作允許、有效。如果此規則用於攔截,則請求消息匹配包含規則列表中的將會被攔截;反之,請求消息匹配去除列表中的將不會被攔截。
從上圖的添加規則對話框中我們可以看出,規則主要由協議、域名或IP地址、端口、文件名4個部分組成,這就意味着我們可以從協議、域名或IP地址、端口、文件名4個維度去控制哪些消息出現在允許或去除在規則列表中。
當我們設置了Target Scope (默認全部為允許),使用Burp Proxy進行代理攔截,在滲透測試中通過瀏覽器代理瀏覽應用時,Burp會自動將瀏覽信息記錄下來,包含每一個請求和應答的詳細信息,保存在Target站點地圖中。
站點地圖 Site Map
下圖所示站點地圖為一次滲透測試中,通過瀏覽器瀏覽的歷史記錄在站點地圖中的展現結果。
從圖中我們可以看出,Site Map的左邊為訪問的URL,按照網站的層級和深度,樹形展示整個應用系統的結構和關聯其他域的url情況;右邊顯示的是某一個url被訪問的明細列表,共訪問哪些url,請求和應答內容分別是什么,都有着詳實的記錄。
基於左邊的樹形結構,我們可以選擇某個分支,對指定的路徑進行掃描和抓取。
同時,我們也可以將某個域直接加入 Target Scope中.
除了加入 Target Scope外,從上圖中,我們也可以看到,對於站點地圖的分層,可以通過折疊和展開操作,更好的分析站點結構。
Target 工具的使用
Target 工具的使用的使用主要包括以下部分:
- 手工獲取站點地圖
- 站點比較
- 攻擊面分析
當我們手工獲取站點地圖時,需要遵循以下操作步驟:
1.設置瀏覽器代理和Burp Proxy代理,並使之能正常工作。
2.關閉Burp Proxy的攔截功能。
3.手工瀏覽網頁,這時,Target會自動記錄站點地圖信息。
手工獲取站點地圖的方式有一個好處就是,我們可以根據自己的需要和分析,自主地控制訪問內容,記錄的信息比較准確。與自動抓取相比,則需要更長的時間,如果需要滲透測試的產品系統是大型的系統,則對於系統的功能點依次操作一遍所需要的精力和時間對滲透測試人員來說付出都是很大的。
站點比較是一個Burp提供給滲透測試人員對站點進行動態分析的利器,我們在比較帳號權限時經常使用到它。當我們登陸應用系統,使用不同的帳號,帳號本身在應用系統中被賦予了不同的權限,那么帳號所能訪問的功能模塊、內容、參數等都是不盡相同的,此時使用站點比較,能很好的幫助滲透測試人員區分出來。一般來說,主要有以下3種場景:
1.同一個帳號,具有不同的權限,比較兩次請求結果的差異。
2.兩個不同的帳號,具有不同的權限,比較兩次請求結果的差異。
3.兩個不同的帳號,具有相同的權限,比較兩次請求結果的差異。
下面我們就一起來看看如何進行站點比較。
1.首先我們在需要進行比較的功能鏈接上右擊,找到站點比較的菜單,點擊菜單進入下一步。
2.由於站點比較是在兩個站點地圖之間進行的,所以我們在配置過程中需要分別指定Site Map 1和Site Map2。通常情況下,Site Map 1 我們默認為當前會話。如圖所示,點擊【Next】。
3.這時我們會進入Site Map 1 設置頁面,如果是全站點比較我們選擇第一項,如果僅僅比較我們選中的功能,則選擇第二項。如下圖,點擊【Next】。如果全站點比較,且不想加載其他域時,我們可以勾選只選擇當前域。
4.接下來就是Site Map 2 的配置,對於Site Map 2我們同樣有兩種方式,第一種是之前我們已經保存下來的Burp Suite 站點記錄,第二種是重新發生一次請求作為Site Map2.這里,我們選擇第二種方式。
5.如果上一步選擇了第二種方式,則進入請求消息設置界面。在這個界面,我們需要指定通信的並發線程數、失敗重試次數、暫停的間隙時間。
6.設置完Site Map 1 和Site Map 2之后,將進入請求消息匹配設置。在這個界面,我們可以通過URL文件路徑、Http請求方式、請求參數、請求頭、請求Body來對匹配條件進行過濾。
7..設置請求匹配條件,接着進入應答比較設置界面。在這個界面上,我們可以設置哪些內容我們指定需要進行比較的。從下圖我們可以看出,主要有響應頭、form表單域、空格、MIME類型。點擊【Next】。
8.如果我們之前是針對全站進行比較,且是選擇重新發生一次作為Site Map2的方式,則界面加載過程中會不停提示你數據加載的進度,如果涉及功能請求的鏈接較少,則很快進入比較界面。如下圖。
9.從上圖我們可以看到,站點比較的界面上部為篩選過濾器(這個過濾器與其他過濾器使用雷同,此處不再贅述),下部由左、中、右三塊構成。左邊為請求的鏈接列表,中間為Site Map 1 和Site Map 2的消息記錄,右邊為消息詳細信息。當我們選擇Site Map 1某條消息記錄時,默認會自動選擇Site Map 2與之對應的記錄,這是有右上角的【同步選擇】勾選框控制的,同時,在右邊的消息詳細區域,會自動展示Site Map 1與Site Map 2通信消息的差異,包含請求消息和應答消息,存在差異的地方用底色標注出來。
攻擊面分析是Burp Suite 交互工具(Engagement tools)中的功能,這里我們先看看Analyze Target使用,其他的功能會在高級使用相關章節講述。
1.首先,我們通過站點地圖,打開Analyze Target,如圖所示。
2.在彈出的分析界面中,我們能看到概況、動態URL、靜態URL、參數4個視圖。
3.概況視圖主要展示當前站點動態URL數量、靜態URL數量、參數的總數、唯一的參數名數目,通過這些信息,我們對當前站點的總體狀況有粗線條的了解。
4.動態URL視圖展示所有動態的URL請求和應答消息,跟其他的工具類似,當你選中某一條消息時,下方會顯示此消息的詳細信息。
5.靜態URL視圖與動態URL視圖類似,如圖.
6.參數視圖有上中下三部分組成,上部為參數和參數計數統計區,你可以通過參數使用的次數進行排序,對使用頻繁的參數進行分析;中部為參數對於的使用情況列表,記錄對於的參數每一次的使用記錄;下部為某一次使用過程中,請求消息和應答消息的詳細信息。
在使用攻擊面分析功能時,需要注意,此功能主要是針對站點地圖中的請求URL進行分析,如果某些URL沒有記錄,則不會被分析到。同時,在實際使用中,存在很點站點使用偽靜態,如果請求的URL中不帶有參數,則分析時無法區別,只能當做靜態URL來分析。
第六章 如何使用Burp Spider
通過前一章的學習,我們了解到,存在於Burp Target中的站點信息,我們可以直接傳送到Burp Spider中進行站點信息的爬取。這一章我們重點來學習Burp Spider的使用,主要包含兩個方面:
- Spider控制(Control)
- Spider可選項設置(Options)
Burp Spider的功能主要使用於大型的應用系統測試,它能在很短的時間內幫助我們快速地了解系統的結構和分布情況,下面我們就先來看看Spider控制,
Spider控制
Spider控制界面由Spider 狀態和Spider 作用域兩個功能組成。
Spider 狀態除了顯示當前進度、傳輸情況、請求隊列等統計信息外,還有Spider運行/暫停按鈕與清空隊列按鈕,分別用來控制Spider是否運行和隊列中的數據管理。而Spider 作用域是用來控制Spider的抓取范圍,從圖中我們可以看到有兩種控制方式,一種是使用上一章講的Target Scope,另一種是用戶自定義。當我們選中用戶自定義按鈕,界面改變成下面的樣子,如下圖所示。
此處用戶自定義作用域的配置與Target Scope 的配置完全一致,具體使用方法請參數上一章Target Scope 的配置。
Spider可選項設置
Spider可選項設置由抓取設置、抓取代理設置、表單提交設置、應用登陸設置、蜘蛛引擎設置、請求消息頭設置六個部分組成。
- 抓取設置(Crawls Settings)
-此項是用來控制蜘蛛抓取網頁內容的方式
自上而下依次是:檢查robots.txt 文件、檢測404應答、忽略內容為空的鏈接、爬取根目錄下所有文件和目錄、對每一個動態頁面發送無參數請求、最大鏈接深度、最大請求URL參數數目 - 抓取代理設置(Passive Spidering )
這個設置比較簡單,第一個如果勾選,則爬取時通過Burp Proxy,反之則不通過。第二個設置是控制代理的鏈接深度。默認為0,表示無限深度,即無論有多少層級的URL均需要爬取。 - 表單提交設置(Form Submission)
表單提交設置主要是用來控制在蜘蛛抓取過程中,對於form表單的處理方式,其界面如下圖:
第一個下拉選項中,是對form表單域的處理內容做控制,默認選擇Action URL、method、fields、values,即同時處理請求的url、請求方式GET或者POST、包含哪些屬性名以及屬性值。點擊下拉選項,可以選擇其中一個或者幾個。如下圖:
接下來的設置的控制form表單的處理方式:不提交表單、需要手工確認、使用默認值自動填寫三種方式。
不提交表單的含義是抓取時候不提交表單數據,這個非常好理解;需要手工確認是指當抓取表單時,彈出界面,讓滲透測試人員自己手工確認表單數據;使用默認值自動填寫是對表單的內容,使用下方的各個配置項進行匹配(匹配時可以使用完全匹配和正則表達式匹配兩種方式其一),默認填寫這些值,然后自動進行提交。其界面如下圖所示:
從上圖我們可以看出,對於表單的輸入域我們可以添加和修改以滿足實際情況的需要,如果還有其他的屬性輸入域我們不想每一個都錄入,可以勾選“設置不匹配的屬性值”,統一指定輸入的值。如圖中的555-555-0199@example.com - 應用登陸(Application Login)
此選擇項主要用來控制抓取時,登陸頁面的處理方式。
選擇項依次是:不提交登陸信息、手工確認登陸信息、作為普通表單處理(如果選擇此項,則把登陸表單的form當作其他表單一樣處理,對於登陸表單將使用”表單提交設置” 中的具體配置)、自動提交登陸(選擇此項,需要在下方的輸入框中指定用戶名和密碼) - 蜘蛛引擎設置(Spider Engine)和HTTP 消息頭設置(Requests Header)
其中蜘蛛引擎設置主要是用來控制蜘蛛抓取的線程數、網絡失敗時重試的次數、重試暫停間隙等,而HTTP 消息頭設置是用來設置Http請求的消息頭自定義,比如說,我們可以編輯消息頭信息,可以指定請求為移動設備,或者不同的手機型號,或者指定為Safari瀏覽器,指定HTTP協議版本為1.1、使用referer等。
第七章 如何使用Burp Scanner
Burp Scanner的功能主要是用來自動檢測web系統的各種漏洞,我們可以使用Burp Scanner代替我們手工去對系統進行普通漏洞類型的滲透測試,從而能使得我們把更多的精力放在那些必須要人工去驗證的漏洞上。
在使用Burp Scanner之前,我們除了要正確配置Burp Proxy並設置瀏覽器代理外,還需要在Burp Target的站點地圖中存在需要掃描的域和URL模塊路徑。如下圖所示:
當Burp Target的站點地圖中存在這些域或URL路徑時,我們才能對指定的域或者URL進行全掃描或者分支掃描。下面我們就來整體的學習一下,一次完整的Burp Scanner使用大概需要哪些步驟。
本章的主要內容有:
- Burp Scanner基本使用步驟
- Burp Scanner掃描方式
- Burp Scanner掃描報告
- Burp Scanner掃描控制
- Burp Scanner可選項設置
Burp Scanner基本使用步驟
Burp Scanner基本使用主要分為以下15個步驟,在實際使用中可能會有所改變,但大體的環節主要就是下面的這些。
1.確認Burp Suite正常啟動並完成瀏覽器代理的配置。
2.進入Burp Proxy,關閉代理攔截功能,快速的瀏覽需要掃描的域或者URL模塊。
3.當我們瀏覽時,默認情況下,Burp Scanner會掃描通過代理服務的請求,並對請求的消息進行分析來辨別是非存在系統漏洞。同時,當我們打開Burp Target時,也會在站點地圖中顯示請求的URL樹。
4.我們可以有針對性的選擇Burp Target站點地圖下的某個節點上鏈接URL上,彈出右擊菜單,進行Active Scan。然后在彈出的確認框中,點擊【YES】即進行掃描整個域。
6.這時,我們打開Burp Scanner 選項卡,在隊列子選項卡中,會看到當前掃描的進度。如果我們雙擊URL,則彈出掃描結果的提示信息。
7.如果我們在Burp Target站點地圖下選擇某個子目錄進行掃描,則會彈出更優化的掃描選項,我們可以對選項進行設置,指定哪些類型的文件不再掃描范圍之內。
8.當我們再次返回到Burp Scanner 選項卡界面時,選擇的子目錄已經開始在掃描中,其掃描的進度依賴於需要掃描內容的多少。
9.如果我們沒有定義了目標作用域(Target Scope),最簡單的方式就是在Burp Target站點地圖上右擊彈出菜單中添加到作用域,然后自動進行掃描。
10.然后進入Burp Scanner的Live scanning子選項卡,在Live Active Scanning控制塊中,選擇Use suite scope,這樣,Burp Scanner將自動掃描經過Burp Proxy的交互信息。
11.當我們再次使用瀏覽器對需要測試的系統進行瀏覽時,Burp Scanner不會發送額外的請求信息,自動在瀏覽的交互信息的基礎上,完成對請求消息的漏洞分析。
12.此時,當我再返回到Burp Target站點地圖界面,將提示系統可能存在的漏洞情況,以及處理這些漏洞的建議。
13.同時,我們也可以在漏洞提示的請求信息上,將消息發送到Burp Repeater模塊,對漏洞進行分析和驗證。
14.隨着Burp Scanner掃描的進度,在Burp Target站點地圖界面上的issues模塊中的漏洞信息也會不斷的更新。
15.當Burp Scanner掃描完成之后,我們在Burp Target站點地圖的選擇鏈接右擊,依次選擇issues—>report issues for this host 即可導出漏洞報告。
Burp Scanner掃描方式
通過以上的操作步驟我們可以學習到,Burp Scanner掃描方式主要有兩種:主動掃描和被動掃描
- 主動掃描(Active Scanning)
當使用主動掃描模式時,Burp 會向應用發送新的請求並通過payload驗證漏洞。這種模式下的操作,會產生大量的請求和應答數據,直接影響系統的性能,通常使用在非生產環境。它對下列的兩類漏洞有很好的掃描效果:
- 客戶端的漏洞,像XSS、Http頭注入、操作重定向;
- 服務端的漏洞,像SQL注入、命令行注入、文件遍歷。
對於第一類漏洞,Burp在檢測時,會提交一下input域,然后根據應答的數據進行解析。在檢測過程中,Burp會對基礎的請求信息進行修改,即根據漏洞的特征對參數進行修改,模擬人的行為,以達到檢測漏洞的目的。
對於第二類漏洞,一般來說檢測比較困難,因為是發生在服務器側。比如說SQL注入,有可能是返回數據庫錯誤提示信息,也有可能是什么也不反饋。Burp在檢測過程中,采用各個技術來驗證漏洞是否存在,比如誘導時間延遲、強制修改Boolean值,與模糊測試的結果進行比較,已達到高准確性的漏洞掃描報告。
- 被動掃描(Passive Scanning)
當使用被動掃描模式時,Burp不會重新發送新的請求,它只是對已經存在的請求和應答進行分析,這對系統的檢測比較安全,尤其在你授權訪問的許可下進行的,通常適用於生成環境的檢測。一般來說,下列這些漏洞在被動模式中容易被檢測出來:
- 提交的密碼為未加密的明文。
- 不安全的Cookie的屬性,比如缺少的HttpOnly和安全標志。
- cookie的范圍缺失。
- 跨域腳本包含和站點引用泄漏。
- 表單值自動填充,尤其是密碼。
- SSL保護的內容緩存。
- 目錄列表。
- 提交密碼后應答延遲。
- session令牌的不安全傳輸。
- 敏感信息泄露,像內部IP地址,電子郵件地址,堆棧跟蹤等信息泄漏。
- 不安全的ViewState的配置。
- 錯誤或者不規范的Content-type指令。
雖然被動掃描模式相比於主動模式有很多的不足,但同時也具有主動模式不具備的優點,除了前文說的對系統的檢測在我們授權的范圍內比較安全外,當某種業務場景的測試,每測試一次都會導致業務的某方面問題時,我們也可以使用被動掃描模式,去驗證問題是否存在,減少測試的風險。
Burp Scanner掃描報告
當我們對一個系統進行掃描完畢后,通常需要生成掃描報告,Burp Scanner支持的報告類型有HTML和XML兩種格式。無法何種格式的掃描報告,其內容基本一致,主要由以下部分組成。報告樣例可以點擊Burp Scanner report查看.
除了頭部的綜述和目錄外,每一個漏洞的章節通常包含:
1.序號 表示漏洞的序號,如果有多個同樣的漏洞,報告中只會有一個序號。
2.漏洞的類型,可以近似地理解與OWASP的類型相對應。
3.漏洞名稱,具體可參考 Issue Definitions子選項卡。
4.漏洞路徑,漏洞對應的多個URL鏈接。
5.漏洞的發生點,通常為參數名。
6.問題的描述(Issue background) 描述漏洞發生的成因
7.解決建議(Remediation background)提供解決的思路和建議
8.請求消息和應答消息的詳細信息。
如果我們想對某次的掃描結果進行保存,需要Burp Target 的站點地圖子選項卡的問題面板(Issue)上右擊,在彈出的菜單中選擇report Issues進行設置並保存即可。(注意,如果想導出所有的漏洞,需要選中所有的問題列表)
具體導出漏洞報告的步驟如下:
1.選中需要保存的漏洞,右擊彈出菜單,如下圖:
2.在彈出的對話框中選擇需要保存的漏洞報告格式。
3.選擇漏洞明細包含內容。
4.請求消息和應答消息設置。
5.選擇報告包含的哪些漏洞。
6.最后,指定報告存放位置、報告名稱等屬性。
Burp Scanner掃描控制
在對系統做主動掃描時,當我們激活Burp Scanner,掃描控制的相關設置也同時開始了。如下圖所示,當我們在Burp Target 的站點地圖上的某個URL執行Actively scan this host時,會自動彈出過濾設置。
在這里,我們可以設置掃描時過濾多媒體類型的應答、過濾js、css、圖片等靜態資源文件。當我們點擊【next】按鈕,進入掃描路徑分支的選擇界面。如下圖:
以上是Burp Scanner開始掃描前的控制,當我們設置完這些之后,將正式進入掃描階段。此時,在Scan queue隊列界面,會顯示掃描的進度、問題總數、請求數和錯誤統計等信息。
在此界面上,我們可以選中某個記錄,在右擊的彈出菜單中,對掃描進行控制。比如取消掃描、暫停掃描、恢復掃描、轉發其他Burp組件等。如下圖:
同時,在Results界面,自動顯示隊列中已經掃描完成的漏洞明細。
在每一個漏洞的條目上,我們可以選中漏洞。在彈出的右擊菜單中,依次選擇Set severity,對漏洞的等級進行標識。也可以選擇Set confidence,對漏洞是否存在或誤報進行標注。
另外,在Live Scanning選項卡中,我們也可以對請求的域、路徑、IP地址、端口、文件類型進行控制,如下圖:
如果你選中了Use suite Scope,則指定條件與你在Burp Target中的Scope配置完全一致,如果你選擇了Use customs scope,則可以自己定義Scope,對於Scope的詳細配置,請參考Burp Target中的Scope配置相關章節。
Burp Scanner可選項設置
通過前幾節的學習,我們已經知道Burp Scanner有主動掃描和被動掃描兩個掃描方式,在Options子選項卡中,主要是針對這兩種掃描方式在實際掃描中的掃描動作進行設置。具體的設置包含以下部分:
- 攻擊插入點設置(Attack Insertion Points)
Burp Scanner在掃描中,基於原始的請求消息,在每一個插入點構造參數,對原數據進行替換,從而去驗證系統漏洞的存在性。通常,以下位置都會被Burp Scanner選擇為插入點。
- URL請求參數
- Body參數(比如form表單的值,上傳文件、XML參數、JSON參數)
- Cookie參數
- 參數的名稱和個數(通過增加參數個數或者增加參數來驗證漏洞)
- Http Header信息(通過對header信息的篡改來驗證漏洞)
- AFM編碼(對flash通信漏洞的驗證)
- REST風格的參數
對於以上的攻擊插入點,Burp Scanner還是可以通過改變參數的位置來驗證漏洞,Burp Scanner中共有URL to body 、URL to cookie、Body to URL、Body to cookie、Cookie to URL、Cookie to body 六種方式。當我們在掃描驗證中,可以根據實際請求,靈活選擇位置改變的組合,高效快速地驗證漏洞。但我們也應該明白,當我們選中了位置改變來驗證漏洞,即選擇了Burp發送更多的請求,如果是在生成系統中的測試需要慎重。
另外,Burp的攻擊插入點也支持嵌套的方式,這意思是指,如果一個請求的參數值是JSON對象或者XML文本,Burp Scanner在掃描時,可以對JSON對象或XML文本中的屬性、屬性值進行驗證,這會極大地提高了Burp Scanner對漏洞掃描的涉及面。這是由上圖中的use nested insertion points的checkbox是否選中去控制的,默認情況下是選中生效的。
當我們設置攻擊插入點的同時,我們也可以指定哪些參數進行跳過,不需要進行漏洞驗證。在設置時,Burp是按照服務器端參數跳過和所有參數均跳過兩種方式來管理的,界面如下圖:
2 主動掃描引擎設置(Active Scanning Engine)
主動掃描引擎設置主要是用來控制主動掃描時的線程並發數、網絡失敗重試間隔、網絡失敗重試次數、請求延遲、是否跟蹤重定向。其中請求延遲設置(Throttle between requests)和其子選項延遲隨機數 (Add random variations to throttle)在減少應用負荷,模擬人工測試,使得掃描更加隱蔽,而不易被網絡安全設備檢測出來。
至於這些參數的具體設置,需要你根據服務器主機的性能、網絡帶寬、客戶端測試機的性能做相應的調整。一般來說,如果您發現該掃描運行緩慢,但應用程序表現良好,你自己的CPU利用率較低,可以增加線程數,使您的掃描進行得更快。如果您發現發生連接錯誤,應用程序正在放緩,或你自己的電腦很卡,你應該減少線程數,加大對網絡故障的重試次數和重試之間的間隔。
3.主動掃描優化設置(Active Scanning Optimization)
此選項的設置主要是為了優化掃描的速度和准確率,盡量地提高掃描速度的同時降低漏洞的誤報率。
掃描速度(Scan speed)分快速、普通、徹底三個選項,不同的選項對應於不同的掃描策略,當選擇徹底掃描(Thorough)時,Burp會發送更多的請求,對漏洞的衍生類型會做更多的推導和驗證。而當你選擇快速掃描(Fast),Burp則只會做一般性的、簡單的漏洞驗證。
掃描精准度(Scan accuracy)也同樣分為三個選項:最小化假陰性(Minimize false negatives)、普通、最小化假陽性(Minimize false positives)。掃描精准度主要是用來控制Burp的掃描過程中針對漏洞的測試次數。當我們選擇最小化假陽性時,Burp會做更多的驗證測試,來防止假陽性漏洞的存在,但也是恰恰基於此,當Burp做更多的驗證測試時,可能存在恰好無法獲取應答的誤報,增加了漏洞的噪音。
智能攻擊選擇(Use intelligent attack selection )這個選項通過智能地忽略一些攻擊插入點基值的檢查,比如說一個參數值包含不正常出現在文件名中的字符,Burp將跳過文件路徑遍歷檢查此參數,使用此選項可加速掃描,並降低在提升掃描速度的同時會導致漏報率上升的風險。
4.主動掃描范圍設置(Active Scanning Areas)
在主動掃描過程中,你可以根據你的掃描時間、關注的重點、可能性存在的漏洞類型等情況,選擇不同的掃描范圍。這里可選擇的掃描范圍有:
- SQL注入 -可以使不同的測試技術(基於誤差,時間延遲測試和布爾條件測試),並且也使檢查所特有的單獨的數據庫類型(MSSQL,Oracle和MySQL的)。
- 操作系統命令注入 - (信息通知和盲注)。
- 反射式跨站點腳本
- 存儲的跨站點腳本
- 文件路徑遍歷
- HTTP頭注入
- XML/ SOAP注入
- LDAP注入
- URL重定向
- http消息頭可操縱
- 服務器的問題
5.被動掃描范圍設置(Passive Scanning Areas)
因為被動掃描不會發送新的請求,只會對原有數據進行分析,其掃描范圍主要是請求和應答消息中的如下參數或漏洞類型:Headers、Forms、Links、Parameters、Cookies、MIME type、Caching、敏感信息泄露、Frame框架點擊劫持、ASP.NET ViewState 。
第八章 如何使用Burp Intruder
Burp Intruder作為Burp Suite中一款功能極其強大的自動化測試工具,通常被系統安全滲透測試人員被使用在各種任務測試的場景中。本章我們主要學習的內容有:
- Intruder使用場景和操作步驟
- Payload類型與處理
- Payload 位置和攻擊類型
- 可選項設置(Options)
- Intruder 攻擊和結果分析
Intruder使用場景和操作步驟
在滲透測試過程中,我們經常使用Burp Intruder,它的工作原理是:Intruder在原始請求數據的基礎上,通過修改各種請求參數,以獲取不同的請求應答。每一次請求中,Intruder通常會攜帶一個或多個有效攻擊載荷(Payload),在不同的位置進行攻擊重放,通過應答數據的比對分析來獲得需要的特征數據。Burp Intruder通常被使用在以下場景:
- 標識符枚舉
Web應用程序經常使用標識符來引用用戶、賬戶、資產等數據信息。例如,用戶名,文件ID和賬戶號碼。 - 提取有用的數據
在某些場景下,而不是簡單地識別有效標識符,你需要通過簡單標識符提取一些其他的數據。比如說,你想通過用戶的個人空間id,獲取所有用戶在個人空間標准的昵稱和年齡。 - 模糊測試
很多輸入型的漏洞,如SQL注入,跨站點腳本和文件路徑遍歷可以通過請求參數提交各種測試字符串,並分析錯誤消息和其他異常情況,來對應用程序進行檢測。由於的應用程序的大小和復雜性,手動執行這個測試是一個耗時且繁瑣的過程。這樣的場景,您可以設置Payload,通過Burp Intruder自動化地對Web應用程序進行模糊測試。
通常來說,使用Burp Intruder進行測試,主要遵循以下步驟:
- 確認Burp Suite安裝正確並正常啟動,且完成了瀏覽器的代理設置。
- 進入Burp Proxy選項卡,關閉代理攔截功能。
- 進行歷史日志(History)子選項卡,查找可能存在問題的請求日志,並通過右擊菜單,發送到Intruder。
- 進行Intruder 選項卡,打開Target和Positions子選項卡。這時,你會看到上一步發送過來的請求消息。
- 因為我們了解到Burp Intruder攻擊的基礎是圍繞剛剛發送過來的原始請求信息,在原始信息指定的位置上設置一定數量的攻擊載荷Payload,通過Payload來發送請求獲取應答消息。默認情況下,Burp Intruder會對請求參數和Cookie參數設置成Payload position,前綴添加 $符合,如上圖紅色標注位置所示。當發送請求時,會將$標識的參數替換為Payload。
- 在Position界面的右邊,有【Add $】、【Clear $】、【Auto $】、【Refersh $】四個按鈕,是用來控制請求消息中的參數在發送過程中是否被Payload替換,如果不想被替換,則選擇此參數,點擊【Clear $】,即將參數前綴$去掉。
- 當我們打開Payload 子選項卡,選擇Payload的生成或者選擇策略,默認情況下選擇“Simple list”,當然你也可以通過下拉選擇其他Payload類型或者手工添加。
- 此時,我們再回到Position界面,在界面的右上角,點擊【Start attack】,發起攻擊。
- 此時,Burp會自動打開一個新的界面,包含攻擊執行的情況、Http狀態碼、長度等結果信息。
- 我們可以選擇其中的某一次通信信息,查看請求消息和應答消息的詳細。
- 很多時候,為了更好的標明應答消息中是否包含有我們需要的信息,通常在進行攻擊前,會進行Options選項的相關配置,使用最多的為正則表達式匹配(Grep - Match)。
- 或者,我們使用結果選項卡中的過濾器,對結果信息進行篩選。
- 同時,結果選項卡中所展示的列我們是可以進行指定的,我們可以在菜單Columns進行設置。
- 最后,選擇我們需要的列,點擊【Save】按鈕,對攻擊結果進行保存。
- 當然,保存之前我們也可以對保存的內容進行設置。
以上這些,是Burp Intruder一次完成的操作步驟,在實際使用中,根據每一個人的使用習慣,會存在或多或少的變動。而每一個環節中涉及的更詳細的配置,將在接下來的章節中做更細致的闡述。
Payload類型與處理
在Burp Intruder的Payload選項卡中,有Payload集合的設置選項,包含了經常使用的Payload類型,共18種。
他們分別是:
簡單列表(Simple list) ——最簡單的Payload類型,通過配置一個字符串列表作為Payload,也可以手工添加字符串列表或從文件加載字符串列表。其設置界面如下圖
在此操作界面上,選擇的Payload列表中,已經預定義了一組簡單Payload列表,包括XSS腳本、CGI腳本、SQL注入腳本、數字、大寫字母、小寫字母、用戶名、密碼、表單域的字段名、IIS文件名和目錄名等等,極大地方便了滲透測試人員的使用。運行時文件(Runtime file) ——指定文件,作為相對應Payload位置上的Payload列表。其設置界面如下圖:
當我們如上圖所示,指定Payload set的位置1使用的Payload類型為Runtime file時,下方的Payload Options將自動改變為文件選擇按鈕和輸入框,當我們點擊【select file】選擇文件時,將彈出圖中所示的對話框,選擇指定的Payload文件。運行時,Burp Intruder將讀取文件的每一行作為一個Payload。自定義迭代器(Custom iterator)——這是一款功能強大的Payload,它共有8個占位,每一個占位可以指定簡單列表的Payload類型,然后根據占位的多少,與每一個簡單列表的Payload進行笛卡爾積,生成最終的Payload列表。例如,某個參數的值格式是username@@password,則設置此Payload的步驟是:位置1,選擇Usernames
接着,指定位置2,輸入值@@
最后指定位置3,選擇Passwords
當我們開始攻擊時,生成的Payload值如圖所示字符串替換(Character substitution)——顧名思義,此種Payload的類型是對預定義的字符串進行替換后生成新的Payload。比如說,預定義字符串為ABCD,按照下圖的替換規則設置后,將對AB的值進行枚舉后生成新的Payload。
生成的Payload如下圖所示,分別替換了上圖中的a和b的值為4與8大小寫替換(Case modification)——對預定義的字符串,按照大小寫規則,進行替換。比如說,預定義的字符串為Peter Wiener,則按照下圖的設置后,會生成新的Payload。
生成的Payload如下
生成規則由上而下依次是:No change(不改變,使用原始字符串)、To lower case(轉為小寫字母)、To upper case(轉為大寫字母)、To Propername(首字母大寫,其他小寫)、To ProperName(首字母大寫,其他不改變),在實際使用中,可以根據自己的使用規則進行勾選設置。遞歸grep (Recursive grep)——此Payload類型主要使用於從服務器端提取有效數據的場景,需要先從服務器的響應中提取數據作為Payload,然后替換Payload的位置,進行攻擊。它的數據來源了原始的響應消息,基於原始響應,在Payload的可選項設置(Options)中配置Grep規則,然后根據grep去提取數據才能發生攻擊。比如,我在 grep extract 中設置取服務器端的EagleId作為新的Payload值。
點擊上圖的【OK】按鈕之后,完成了Payload的設置。
當我發起攻擊時,Burp會對每一次響應的消息進行分析,如果提取到了EagleId的值,則作為Payload再發生一次請求。操作圖如下:
上圖中請求序號為偶數的消息的Payload都是上一次服務器端響應的報文中的EagleId的值。不合法的Unicode編碼(Illegal Unicode)—— 在payloads里用指定的不合法Unicode 編碼替換字符本身,從這些Payload列表里產生出一個或者多個有效負荷。在嘗試回避基於模式匹配的輸入驗證時,這個有效負荷會有用的,例如,在防御目錄遍歷攻擊時../和..序列的期望編碼的匹配。其配置界面如下:
上圖中的配置選項主要用來控制不合法編碼的生成,各項的含義如下:
maximum overlong UTF-8 length Unicode 編碼允許最多使用 6 字節表示一個字符。使用一種類型就可以正確地表示出(0x00-0x7F) Basic ASCII 字符。然而,使用多字節的Unicode 方案也能表示出它們(如, ”overlong”編碼)。下拉菜單用來指定是否使用超長編碼,以及應該設定的最大使用長度。
Illegal UTF-8 continuation bytes 當選擇的最大超長 UTF-8 長度為 2 字節以上,這個選項是可用的。
Do illegal UTF-8 當使用多字節編碼一個字符時,第一個字節后面的字節應該用 10XXXXXX 這樣的二進制格式,來指出后續的字節。然而,第一個字節里最有意義的位會指出后面還有多少后續字節。因此,Unicode 編碼例程會安全地忽略掉后續字節的前 2 位。這就意味着每個后續字節可能有 3 個非法變種,格式為 00XXXXXX, 01XXXXXX 和 11XXXXXX。如果選中這個選項,則非法 Unicode 有效負荷源會為每個后續字節生成 3 個附加編碼。
Maximize permutations in multi-byte encodings 如果選擇的最大超長 UTF-8 長度為 3 字節以上,並且選中” illegal UTF-8 ”這個選項可用。如果”Maximize permutations in multi-byte encodings”沒被選中,則在生產非法變種時,不合法 Unicode 有效負荷源會按順序處理每個后續字節,為每個后續字節產生 3 個非法變種,並且其他的后續字節不會改變。如果”Maximize permutations in multi-byte encodings”被選中了,不合法 的Unicode 有效負荷源會為后續字節生成所有的非法變種排序 。 如,多個后續字節會同時被修改。在目標系統上回避高級模式匹配控制時,這個功能就會很有用。
Illegal hex 這個選擇基本上一直可用。當使用超長編碼和后續字節的非法變種(如果選中)生成非法編碼項列表時,通過修改由此產生的十六進制編碼可能會迷惑到某種模式匹配控制。十六進制編碼使用字符 A—F 代表十進制 10—15 的值。然而有些十六進制編碼會把G解釋為 16, H 為 17,等等。因此 0x1G 會被解釋為 32。另外,如果非法的十六進制字符使用在一個 2 位數的十六進制編碼的第一個位置,則由此產生的編碼就會溢出單個字節的大小,並且有些十六進制編碼只使用了結果數字的后 8 個有效位,因此 0x1G 會被解碼為 257,而那時會被解釋為 1。每個合法的 2 位數的十六進制編碼有 4—6 種相關的非法十六進制表示,如果使用的是上面的編碼,則這些表示會被解釋為同一種十六進制編碼。如果”illegal hex”被選中,則非法 Unicode 有效負荷源會在非法編碼項列表里,生成每個字節的所有可能的非法十六進制編碼。
Maximize permutations in multi-byte encodings 如果選中的最大超長 UTF-8 長度為 2 字節以上並且“illegal hex”也被選中,則這個選項可用。如果Maximize permutations in multi-byte encodings”沒被選中,在生成非法十六進制編碼時,非法 Unicode 有效負荷源會按順序處理每個字節。對於每個字節,會生成 4—6 個非法十六進制編碼,其他的字節不變。如果Maximize permutations in multi-byte encodings”被選中,則非法 Unicode 有效負荷源會為所有的字節,生成非法十六進制的所有排序。如,多個字節會被同時修改。在目標系統上回避高級模式匹配控制時,這個功能會非常有用。
add % prefix 如果選中這個選項,在產生的有效負荷里的每個 2 位數十六進制編碼前面,都會插入一個%符號。
Use lower case alpha characters 這個選項決定了是否在十六進制編碼里使用大小寫字母。
Total encodings 這個選項為會產生的非法編碼數量放置了一個上界,如果大量使用超長編碼或者選中了最大列表,這個選項會很有用,因為那會生成大量的非法編碼。
Match / replace in list items 這個選項用戶控制Payload列表中的字符串,它是由匹配字符(Match character)和替換字符編碼(Replace with encodings of )來成對的控制Payload的生成。當攻擊執行時,這個有效負荷源會迭代所有預設項列表,在非法編碼集合里,每個預設
項替換每個項里的指定字符的所有實例。
字符塊(Character blocks)——這種類型的Payload是指使用一個給出的輸入字符串,根據指定的設置產生指定大小的字符塊,表現形式為生成指定長度的字符串。它通常使用了邊界測試或緩沖區溢出。
Base string 是指設置原始字符串,Min length是指Payload的最小長度,Max length 是指Payload的最大長度,Step是指生成Payload時的步長。如上圖的配置后,生成的Payload如下圖所示:數字類型(Number)——這種類型的Payload是指根據配置,生成一系列的數字作為Payload。它的設置界面如下:
Type表示使用序列還是隨機數,From表示從什么數字開始,To表示到什么數字截止,Step表示步長是多少,如果是隨機數,則How many被激活,表示一共生成多少個隨機數。Base表示數字使用十進制還是十六進制形式,Min integer digits 表示最小的整數是多少,Max integer digits表示最大的整數是多少,如果是10進制,則Min fraction digits 表示小數點后最少幾位數,Max fraction digits表示小數點后最多幾位數。
日期類型(Dates)——這種類型的Payload是指根據配置,生成一系列的日期。界面如下
其設置選項比較簡單,沒有什么特別復雜的,不再贅述。至於日期格式,可以選擇Burp自己提供的樣例格式,也可以自定義,自定義的時候,格式的填寫形式如下表所示格式 樣例 E Sat EEEE Saturday d 7 dd 07 M 6 MM 06 MMM Jun MMMM June yy 16 yyyy 2016 暴力字典(Brute forcer)——此類Payload生成包含一個指定的字符集的所有排列特定長度的有效載荷,通常用於枚舉字典的生成,其設置界面如下:
Character set 表示生成字典的數據集,從此數據集中抽取字符進行生成。Min length表示生成Payload的最小長度,Max length表示生成Payload的最大長度。空類型(Null payloads)——這種負載類型產生的Payload,其值是一個空字符串。在攻擊時,需要同樣的請求反復被執行,在沒有任何修改原始請求的場景下此Payload是非常有用的。它可用於各種攻擊,例如cookie的序列分析、應用層Dos、或保活會話令牌是在其它的間歇試驗中使用。
在配置Payload生成方式時,它有兩個選項,我們可以指定生成(Generate)多少Payload,也可以設置為一直持續攻擊(Continue indefinitely)字符frobber(Character frobber)——這種類型的Payload的生成規律是:依次修改指定字符串在每個字符位置的值,每次都是在原字符上遞增一個該字符的ASCII碼。它通常使用於測試系統使用了復雜的會話令牌的部件來跟蹤會話狀態,當修改會話令牌中的單個字符的值之后,您的會話還是進行了處理,那么很可能是這個令牌實際上沒有被用來追蹤您的會話。其配置界面如圖:
執行后生成的Payload如下圖所示:Bit翻轉(Bit flipper)——這種類型的Payload的生成規律是:對預設的Payload原始值,按照比特位,依次進行修改。它的設置界面如下圖:
其設置選項主要有:Operate on 指定是對Payload位置的原始數據進行Bit翻轉還是指定值進行Bit翻轉,Format of original data 是指是否對原始數據的文本意義進行操作,還是應該把它當作ASCII十六進制,Select bits to flip是指選擇翻轉的Bit位置。
您可以配置基於文本意義進行操作,或基於ASCII十六進制字符串進行翻轉。例如,如果原始值是“ab”,基於文本意義的翻轉結果是:`b cb eb ib qb Ab !b ¡b ac a` af aj ar aB a" a¢
如果是基於ASCII十六進制字符串進行翻轉,則結果是:
aa a9 af a3 bb 8b eb 2b
這種類型的Payload類似於字符frobber,但在你需要更細粒度的控制時是有用的。例如,會話令牌或其他參數值使用CBC模式的塊密碼加密,有可能系統地由前一密碼塊內修改Bit位以改變解密后的數據。在這種情況下,你可以使用的Bit 翻轉的Payload來確定加密值內部修改了個別bit位后是否對應用程序產生影響,並了解應用程序是否容易受到攻擊。關於加密模式可以點擊閱讀這篇文章做進一步的了解。
用戶名生成器(Username generator)這種類型的Payload主要用於用戶名和email帳號的自動生成,其設置界面如下圖:
如上圖所示,我設置了原始值為t0data@hotmail.com,然后執行此Payload生成器,其生成的Payload值如圖所示ECB 加密塊洗牌(ECB block shuffler)——這種類型的Payload是基於ECB加密模式的Payload生成器,關於加密模式可以點擊閱讀這篇文章做進一步的了解。其原理是因為ECB加密模式中每組64位的數據之間相互獨立,通過改變分組數據的位置方式來驗證應用程序是否易受到攻擊。其設置界面如下圖,Payload的配置參數同上一個Payload類型雷同,就不再贅述。如圖:
Burp Payload生成插件(Extension-generated)——這種類型的Payload是基於Burp插件來生成Payload值,因此使用前必須安裝配置Burp插件,在插件里注冊一個Intruder payload生成器,供此處調用。其基本設置和使用步驟如下圖所示,因后續章節將重點敘述Burp插件,此處不再展開。
Payload復制(Copy other payload)——這種類型的Payload是將其他位置的參數復制到Payload位置上,作為新的Payload值,通常適用於多個參數的請求消息中,它的使用場景可能是:
1.兩個不同的參數需要使用相同的值,比如說,用戶注冊時,密碼設置會輸入兩遍,其值也完全一樣,可以使用此Payload類型。
2.在一次請求中,一個參數的值是基於另一個參數的值在前端通過腳本來生成的值,可以使用此Payload類型。
它的設置界面和參數比較簡單,如下圖所示,其中Payload位置的索引值就是指向圖中Payload set的值。
Payload位置和攻擊類型
首先我們來看看Payload位置(Payload positions)選項卡的設置界面:
從上圖中我們可以看出,Payload位置的設置是基於Http請求的原始消息作為母板,使用一對 §字符來標記出Payload的位置,在這兩個號直接包含了母板文本內容。 當我們已經把一個Payload在請求消息的特殊位置上時標明后,發起攻擊時,Burp Intruder 就把一個Payload值放置到給出的特殊位置上,替換 §符號標示的整個位置。如上圖中的參數id后面的 §符號之間的標明的是Payload位置1,name后面的 §符號之間標明的是Payload位置2,這個值對應於Payload設置中的Payload set的值。
我們可以在消息編輯器中間對Payload位置進行編輯,它主要是由右側的四個按鈕來控制的。
- 【Add §】——在當前光標的位置添加一個Payload位置標志
- 【Clear §】——清除所有Payload位置標志或者清除選中的Payload位置標志
【Auto §】——對消息內容中可能需要標志的參數做一個猜測,標志為Payload位置,自動設置完之后再做人工的選擇,確定哪些位置是需要傳入Payload的。目前Burp支持自動選擇的參數類型有:
1.URL請求參數
2.Body參數
3.cookie參數
4.復合型參數屬性,比如文件上傳時候的文件名
5.XML數據
6.JSON數據
雖然Burp默認是支持自動標志這些類型的參數作為Payload位置,但如果是針對於像XML或JSON的節點屬性值的,還是需要手工指定。【Refresh】——刷新消息內容中帶有顏色的部分。
- 【Clear】——清除消息編輯器中所有內容。
在消息編輯器的上方,有一個下拉選擇框,攻擊類型(Attack Type)。Burp Intruder支持使用Payload進行多種方式的模擬攻擊,目前只要有以下4種。
狙擊手模式(Sniper)——它使用一組Payload集合,依次替換Payload位置上(一次攻擊只能使用一個Payload位置)被§標志的文本(而沒有被§標志的文本將不受影響),對服務器端進行請求,通常用於測試請求參數是否存在漏洞。
攻城錘模式(Battering ram)——它使用單一的Payload集合,依次替換Payload位置上被§標志的文本(而沒有被§標志的文本將不受影響),對服務器端進行請求,與狙擊手模式的區別在於,如果有多個參數且都為Payload位置標志時,使用的Payload值是相同的,而狙擊手模式只能使用一個Payload位置標志。
草叉模式(Pitchfork )——它可以使用多組Payload集合,在每一個不同的Payload標志位置上(最多20個),遍歷所有的Payload。舉例來說,如果有兩個Payload標志位置,第一個Payload值為A和B,第二個Payload值為C和D,則發起攻擊時,將共發起兩次攻擊,第一次使用的Payload分別為A和C,第二次使用的Payload分別為B和D。
集束炸彈模式(Cluster bomb) 它可以使用多組Payload集合,在每一個不同的Payload標志位置上(最多20個),依次遍歷所有的Payload。它與草叉模式的主要區別在於,執行的Payload數據Payload組的乘積。舉例來說,如果有兩個Payload標志位置,第一個Payload值為A和B,第二個Payload值為C和D,則發起攻擊時,將共發起四次攻擊,第一次使用的Payload分別為A和C,第二次使用的Payload分別為A和D,第三次使用的Payload分別為B和C,第四次使用的Payload分別為B和D。
可選項設置(Options)
可選項設置主要包括請求消息頭設置、請求引擎設置、攻擊結果設置、grep match, grep extract, grep payloads,以及重定向設置。在使用中,你可以在攻擊前進行設置,也可以在攻擊過程中做這些選項的調整。
- 請求消息頭設置(Request Headers)——這個設置主要用來控制請求消息的頭部信息,它由Update Content-Length header和Set Connection: close兩個選項組成。其中Update Content-Length header如果被選中,Burp Intruder在每個請求添加或更新Content-Length頭為該次請求的HTTP體的長度正確的值。這個功能通常是為插入可變長度的Payload到模板的HTTP請求的主體的攻擊中,如果沒有指定正確的值,則目標服務器可能會返回一個錯誤,可能會到一個不完整的請求做出響應,或者可能會無限期地等待請求繼續接收數據。Set Connection: close如果被選中,表示Burp Intruder在每個請求消息中添加或更新值為“關閉”的連接頭,這將更迅速地執行。在某些情況下(當服務器本身並不返回一個有效的Content-Length或Transfer-Encoding頭),選中此選項可能允許攻擊。
請求引擎設置(Request Engine)——這個設置主要用來控制Burp Intruder攻擊,合理地使用這些參數能更加有效地完成攻擊過程。它有如下參數:Number of threads並發的線程數,Number of retries on network failure 網絡失敗時候重試次數,Pause before retry重試前的暫停時間間隔(毫秒),Throttle between requests 請求延時(毫秒),Start time開始時間,啟動攻擊之后多久才開始執行。
攻擊結果設置(Attack Results)——這個設置主要用來控制從攻擊結果中抓取哪些信息。它的參數有:Store requests / responses 保存請求/應答消息,Make unmodified baseline request 記錄請求母板的消息內容,Use denial-of-service mode使用Dos方式,tore full payloads存儲所有的Payload值。
Grep Match——這個設置主要用來從響應消息中提取結果項,如果匹配,則在攻擊結果中添加的新列中標明,便於排序和數據提取。比如說,在密碼猜測攻擊,掃描諸如“密碼不正確”或“登錄成功”,可以找到成功的登錄;在測試SQL注入漏洞,掃描包含“ODBC”,“錯誤”等消息可以識別脆弱的參數。
其選項有Match type表示匹配表達式還是簡單的字符串,Case sensitive match是否大小寫敏感,Exclude HTTP headers匹配的時候,是否包含http消息頭。Grep Extract——這些設置可用於提取響應消息中的有用信息。對於列表中配置的每個項目,Burp會增加包含提取該項目的文本的新結果列。然后,您可以排序此列(通過單擊列標題)命令所提取的數據。此選項是從應用數據挖掘有用的,能夠支持廣泛的攻擊。例如,如果你是通過一系列文檔ID的循環,可以提取每個文檔尋找有趣的項目的頁面標題。如果您發現返回的其他應用程序用戶詳細信息的功能,可以通過用戶ID重復和檢索有關用戶尋找管理帳戶,甚至密碼。如果“遺忘密碼”的功能需要一個用戶名作為參數,並返回一個用戶配置的密碼提示,您可以通過共同的用戶名列表運行和收獲的所有相關密碼的提示,然后直觀地瀏覽列表尋找容易被猜到密碼。
Grep Payloads——這些設置可用於提取響應消息中是否包含Payload的值,比如說,你想驗證反射性的XSS腳本是否成功,可以通過此設置此項。當此項設置后,會在響應的結果列表中,根據Payload組的數目,添加新的列,顯示匹配的結果,你可以通過點擊列標題對結果集進行排序和查找。
其設置項跟上一個類似,需要注意的是Match against pre-URL-encoded payloads,如果你在請求消息時配置了 URL-encode payloads ,則這里表示匹配未編碼之前的Payload值,而不是轉碼后的值。重定向(Redirections)——這些設置主要是用來控制執行攻擊時Burp如何處理重定向,在實際使用中往往是必須遵循重定向,才能實現你的攻擊目的。例如,在密碼猜測攻擊,每次嘗試的結果可能是密碼錯誤會重定向響應到一個錯誤消息提示頁面,如果密碼正確會重定向到用戶中心的首頁。
但設置了重定向也可能會遇到其他的問題,比如說,在某些情況下,應用程序存儲您的會話中初始請求的結果,並提供重定向響應時檢索此值,這時可能有必要在重定向時只使用一個單線程攻擊。也可能會遇到,當你設置重定向,應用程序響應會重定向到注銷頁面,這時候,按照重定向可能會導致您的會話被終止時。
因其設置選項跟其他模塊的重定向設置基本一致,此處就不再重敘。
Intruder 攻擊和結果分析
一次攻擊的發起,通常有兩種方式。一種是你在Burp Intruder里設置了Target, Positions, Payloads and Options ,然后點擊【Start attack】啟動攻擊;另一種是你打開一個之前保存的預攻擊文件,然后點擊【Start attack】啟動攻擊。無論是哪種方式的攻擊發起,Burp都將彈出攻擊結果界面。在攻擊的過程中,你也可以修改攻擊配置,或者做其他的操作。攻擊結果的界面如下圖所示:
從上圖我們可以看出,其界面主要又菜單區、過濾器、Payload執行結果消息記錄區、請求/響應消息區四大部分組成。
菜單區 包含Attack菜單、Save菜單、Columns菜單。
Attack菜單主要用來控制攻擊行為的,你可以暫停攻擊(pause)、恢復攻擊(resume)、再次攻擊(repeat)。
Save菜單主要用來保存攻擊的各種數據,Attack 保存當前攻擊的副本,下次可以從此文件進行再次攻擊;Results table保存攻擊的結果列表,相當於圖中的Payload執行結果消息記錄區數據,當然你可以選擇行和列進行保存,只導出你需要的數據;Server responses 保存所有的服務器響應消息;Attack configuration保存當前的攻擊配置信息。
Columns菜單主要用來控制消息記錄區的顯示列。如果某個列被選中,則在Payload執行結果消息記錄區顯示,反之則不顯示。過濾器 ——可以通過查詢條件、服務器響應的狀態碼、注釋過Payload執行結果消息記錄區的信息進行過濾。
Payload執行結果消息記錄區,又稱結果列表(Results Table),記錄Payload執行時請求和響應的所有信息,它包含的列有:
請求序列——顯示請求的序列號,如果配置了記錄未修改的請求消息母板,則會在第一個進行記錄。
Payload位置——狙擊手模式下會記錄
Payload值——如果有多個Payload,則存在多個列
HTTP 狀態碼——服務器響應狀態碼
請求時間——執行攻擊的時間
響應時間——開始接受到響應時間,單位為毫秒。
響應完成時間——響應完成的時間,單位為毫秒。
網絡錯誤——Payload執行時是否發生網絡問題
超時情況——等待應答響應過程中,是否發生網絡超時
長度——響應消息的長度
Cookie——任何的Cookie信息
Grep——如果設置了Grep 匹配、Grep 提取、Grep Payload,則會有多個列顯示匹配的信息
重定向——如果配置了重定向,則顯示
注釋——消息記錄的注釋信息請求/響應消息區——參考Proxy章節的相關敘述。
在對攻擊結果的分析中,你可以通過單擊任一列標題(單擊標題循環通過升序排序,降序排序和未排序)重新排序表的內容。有效地解釋攻擊的結果的一個關鍵部分是定位有效的或成功的服務器響應,並確定生成這些請求。有效的應答通常可以通過以下中的至少一個存在差異:
1.不同的HTTP狀態代碼
2.不同長度的應答
3.存在或不存在某些表達式
4.錯誤或超時的發生
5.用來接收或完成響應時間的差異
比如說,在URL路徑掃描過程中,對不存在的資源的請求可能會返回“404未找到”的響應,或正確的URL會反饋的“200 OK”響應。或者在密碼猜測攻擊,失敗的登錄嘗試可能會產生一個包含“登錄失敗”關鍵字“200 OK”響應,而一個成功的登錄可能會生成一個“302對象移動”的反應,或不同的“200 OK”響應頁面。
每一個滲透測試人員,對Burp Intruder 攻擊結果的分析方式可能會存在差異,這主要源於個人水平的不同和經驗的不同。在實戰中,只有慢慢嘗試,積累,才能通過快速地對攻擊結果的分析獲取自己關注的重要信息。
第九章 如何使用Burp Repeater
Burp Repeater作為Burp Suite中一款手工驗證HTTP消息的測試工具,通常用於多次重放請求響應和手工修改請求消息的修改后對服務器端響應的消息分析。本章我們主要學習的內容有:
- Repeater的使用
- 可選項設置(Options)
Repeater的使用
在滲透測試過程中,我們經常使用Repeater來進行請求與響應的消息驗證分析,比如修改請求參數,驗證輸入的漏洞;修改請求參數,驗證邏輯越權;從攔截歷史記錄中,捕獲特征性的請求消息進行請求重放。Burp Repeater的操作界面如下圖所示:
請求消息區為客戶端發送的請求消息的詳細信息,Burp Repeater為每一個請求都做了請求編號,當我們在請求編碼的數字上雙擊之后,可以修改請求的名字,這是為了方便多個請求消息時,做備注或區分用的。在編號的下方,有一個【GO】按鈕,當我們對請求的消息編輯完之后,點擊此按鈕即發送請求給服務器端。服務器的請求域可以在target處進行修改,如上圖所示。
應答消息區為對應的請求消息點擊【GO】按鈕后,服務器端的反饋消息。通過修改請求消息的參數來比對分析每次應答消息之間的差異,能更好的幫助我們分析系統可能存在的漏洞。
在我們使用Burp Repeater時,通常會結合Burp的其他工具一起使用,比如Proxy的歷史記錄,Scanner的掃描記錄、Target的站點地圖等,通過其他工具上的右擊菜單,執行【Send to Repeater】,跳轉到Repeater選項卡中,然后才是對請求消息的修改以及請求重放、數據分析與漏洞驗證。
可選項設置(Options)
與Burp其他工具的設置不同,Repeater的可選項設置菜單位於整個界面頂部的菜單欄中,如圖所示:
其設置主要包括以下內容:
更新Content-Length
這個選項是用於控制Burp是否自動更新請求消息頭中的Content-Length解壓和壓縮(Unpack gzip / deflate )
這個選項主要用於控制Burp是否自動解壓或壓縮服務器端響應的內容跳轉控制(Follow redirections)
這個選項主要用於控制Burp是否自動跟隨服務器端作請求跳轉,比如服務端返回狀態碼為302,是否跟着應答跳轉到302指向的url地址。
它有4個選項,分別是永不跳轉(Never),站內跳轉(On-site only )、目標域內跳轉(In-scope only)、始終跳轉(Always),其中永不跳轉、始終跳轉比較好理解,站內跳轉是指當前的同一站點內跳轉;目標域跳轉是指target scope中配置的域可以跳轉;跳轉中處理Cookie(Process cookies in redirections )
這個選項如果選中,則在跳轉過程中設置的Cookie信息,將會被帶到跳轉指向的URL頁面,可以進行提交。視圖控制(View)
這個選項是用來控制Repeater的視圖布局其他操作(Action)
通過子菜單方式,指向Burp的其他工具組件中。
第十章 如何使用Burp Sequencer
Burp Sequencer作為Burp Suite中一款用於檢測數據樣本隨機性質量的工具,通常用於檢測訪問令牌是否可預測、密碼重置令牌是否可預測等場景,通過Sequencer的數據樣本分析,能很好地降低這些關鍵數據被偽造的風險。本章我們主要學習的內容有:
- Sequencer使用步驟
- 可選項設置(Options)
Sequencer使用步驟
Burp Sequencer作為一款隨機數分析的工具,在分析過程中,可能會對系統造成不可預測的影響,在你不是非常熟悉系統的情況下,建議不要在生產環境進行數據分析。它的使用步驟大體如下:
1.首先,確認Burp Suite安裝正確,並配置好瀏覽器代理,正常運行。
2.從Burp Proxy的歷史日志記錄中,尋找token或類似的參數,返回右擊彈出上下文菜單,點擊【Send to Sequencer】。
3.進入Burp Sequencer的Live Capture面板,選中剛才發送過來的記錄,點擊【Configure】配置需要分析的token或者參數。
4.在彈出的參數配置對話框中,選中參數的值,點擊【OK】按鈕,完成參數設置。
5.點擊【Select Live Capture】,開始進行參數值的獲取。
6.當抓取的參數值總數大於100時,點擊【pause】或者【stop】,這時可以進行數據分析,點擊【Analyze now】即進行數據的隨機性分析。
7.等分析結束,則可以看到分析結果的各種圖表。
8.當然,我們也可以把獲取的數據保存起來,下一次使用的時候,從文件加載參數,進行數據分析。如下圖保存數據。
9.當我再次使用時,直接加載數據進行分析即可。
可選項設置(Analysis Options)
分析可選項設置的目的主要是為了控制token或者參數,在進行數據分析過程中,需要做什么樣的處理,以及做什么類型的隨機性分析。它主要由令牌處理(Token Handling)和令牌分析(Token Analysis)兩部分構成。
令牌處理Token Handling主要控制令牌在數據分析中如何被處理,它的設置界面如下圖所示:
其中Pad short tokens at start / end 表示如果應用程序產生的令牌是具有可變長度的,那么這些令牌在數據分析前都需要被填充,以便於進行的統計檢驗。你可以選擇是否填充在開始位置或每個令牌的結束位置。在大多數情況下,在開始位置填充是最合適。
Pad with 表示你可以指定將用於填充的字符。在大多數情況下,數字或ASCII十六進制編碼的令牌,用“0”填充是最合適的。
Base64-decode before analyzing表示在數據分析是否進行base64解碼,如果令牌使用了base64編碼的話,則需要勾選此項。令牌分析Token Analysis主要用來控制對數據進行隨機性分析的類型,我們可以選擇多個分析類型,也可以單獨啟用或禁用每個字符類型級和字節級測試。有時候,執行與啟用所有分析類型進行初步分析后,再禁用某些分析類型,以便更好地了解令牌的特點,或隔離由樣品表現任何不尋常的特性。其設置界面如下:
其中上面兩個選項是控制數據分析的字符類型級,它包含Count和Transitions。
Count是指分析在令牌內的每個位置使用的字符的分布,如果是隨機生成的樣本,所用字符的分布很可能是大致均勻的。在每個位置上分析統計令牌是隨機產生的分布的概率。其分析結果圖表如下所示:
Transitions是指分析樣品數據中的連續符號之間的變化。如果是隨機生成的樣品,出現在一個給定的位置上的字符是同樣可能通過在該位置使用的字符中的任一項中的下一個標志的改變。在每個位置上統計分析令牌隨機產生到變化的概率。其分析結果圖表如下所示:
下面的幾項設置是用於控制數據分析的字節級測試,它比字符級測試功能更強大。啟用字節級分析中,每個令牌被轉換成一組字節,與設置在每個字符位置的字符的大小決定的比特的總數。它包含的測試類型有以下七種。
FIPS monobit test——它測試分析0和1在每個比特位置的分配,如果是隨機生成的樣本,1和0的數量很可能是大致相等。Burp Sequencer 記錄每個位是通過還是沒通過FIPS試驗觀測。值得注意的是,FIPS測試正式規范假定樣本總數為20000個時。如果你希望獲得的結果與該FIPS規范一樣嚴格的標准,你應該確保達到20000個令牌的樣本。
其分析結果圖表如下所示:
FIPS poker test—— 該測試將j比特序列划分為四個連續的、非重疊的分組,然后導出4個數,計算每個數字出現16個可能數字的次數,並采用卡方校驗來評估數字的分布。如果樣品是隨機生成的,這個數字的分布可能是近似均勻的。在每個位置上,通過該測試方式,分析令牌是隨機產生的分布的概率。其分析結果圖表如下所示:
FIPS runs tests —— 該測試將具有相同值的連續的比特序列在每一個位置進行划分成段,然后計算每一個段的長度為1,2,3,4,5,和6以及6以上。如果樣品是隨機生成的,那么這些段的長度很可能是由樣本集的大小所確定的范圍之內。在每個位置上,使用該分析方法,觀察令牌是隨機生成的概率。其分析結果圖表如下所示:
FIPS long runs test —— 這個測試將有相同值的連續的比特序列在每一個位置進行划分成段,統計最長的段。如果樣品是隨機生成的,最長的段的數量很可能是由樣本集的大小所確定的范圍之內。在每個位置上,使用此分析方法,觀察令牌是隨機產生的最長段的概率。其分析結果圖表如下所示:
Spectral tests —— 該測試是在比特序列的每個位置上做一個復雜的分析,並且能夠識別某些樣品是通過其他統計檢驗的非隨機性證據。樣本試驗通過比特序列和將每個系列的連續的數字作為多維空間的坐標並通過它繪制在這些坐標來確定每個位置這個空間的一個點。如果是隨機生成的樣本,點的此空間中的分布可能是大致均勻;在該空間內的簇的外觀表示數據很可能是非隨機的。在每個位置,使用此種分析方法,觀察令牌是隨機發生的概率。其分析結果圖表如下所示:
Correlation test ——比較每個位置具有相同值的令牌樣本與每一個位置具有不同值的短令牌樣本之間的熵,以測試在令牌內部的不同的比特位置中的值之間的任何統計學顯著關系。如果樣品是隨機生成的,在給定的比特位置處的值是同樣可能伴隨着一個或一個零在任何其它位的位置。在每個位置上,使用此種分析方法,觀察令牌是隨機生成的可能性。為了防止任意的結果,當兩個比特之間觀察到一定程度的相關性,該測試調整,其顯着性水平下是基於所有其他比特級測試的位的顯着性水平。其分析結果圖表如下所示:
Compressoion test —— 這種測試不使用其他測試中使用的統計方法,而是通過簡單直觀的指標統計比特序列中每個位置熵的數量。該分析方法嘗試使用標准ZLIB壓縮比特序列的每個位置,結果表明,當它被壓縮在比特序列的大小的比例減少,較高壓縮程度表明數據是不太可能被隨機產生的。其分析結果圖表如下所示:
本章涉及諸多數學統計分析的知識,在表述或理解過程中由於知識水平的限制可能會存在錯誤,如果有問題的地方,歡迎發送郵件到 t0data@hotmail.com,先感謝您的批評指正。
第十一章 如何使用Burp Decoder
Burp Decoder的功能比較簡單,作為Burp Suite中一款編碼解碼工具,它能對原始數據進行各種編碼格式和散列的轉換。其界面如下圖,主要由輸入域、輸出域、編碼解碼選項三大部分組成。
輸入域即輸入需要解碼的原始數據,此處可以直接填寫或粘貼,也可以通過其他Burp工具的上下文菜單中【Send to Decoder】;輸出域即對輸入域進行解碼的結果顯示出來。無論是輸入域還是輸出域都支持文本與Hex兩種格式,其中編碼解碼選項中,由解碼選項(Decode as)、編碼選項(Encode as)、散列(Hash)三個構成。實際使用中,可以根據場景的需要進行設置。對於編碼解碼選項,目前支持URL、HTML、Base64、ASCII、16進制、8進制、2進制、GZIP共八種形式的格式轉換,Hash散列支持SHA、SHA-224、SHA-256、SHA-384、SHA-512、MD2、MD5格式的轉換,更重要的是,對於同一個數據,我們可以在Decoder的界面,進行多次編碼解碼的轉換。如下圖所示:
第十二章 如何使用Burp Comparer
2.使用 Intruder 進行攻擊時,對於不同的服務器端響應,可以很快的分析出兩次響應的區別在哪里。
3.進行SQL注入的盲注測試時,比較兩次響應消息的差異,判斷響應結果與注入條件的關聯關系。
其界面如下圖:

對於Comparer的使用,主要有兩個環節組成,先是數據加載,然后是差異分析。
Comparer數據加載的方式常用的有:從其他Burp工具通過上下文菜單轉發過來、直接粘貼、從文件加載三種方式。當加載完畢后,如果你選擇了兩次不同的請求或應答消息,則下發的比較按鈕將被激活,可以選擇文本比較或者字節比較。如下圖:

如果點擊了【words】或者【bytes】,則進入比對界面,頁面自動通過背景顏色顯示數據的差異。如下圖:

其中,文本比較(words)是指通過文本的方式,比如說以HTML的方式,比較兩個數據的差異;而字節比較(bytes)是指通過16進制的形式,比較兩次內容的差異。如下圖,注意下發不同內容的顏色標注。
