Burp Suite是一個集成化的滲透測試工具,它集合了多種滲透測試組件,使咱們自動化地或手工地能更好的完成對web應用的滲透測試和攻擊。在滲透測試中,咱們使用Burp Suite將使得測試工做變得更加容易和方便,即便在不須要嫺熟的技巧的狀況下,只有咱們熟悉Burp Suite的使用,也使得滲透測試工做變得輕鬆和高效。css
Burp Suite是由Java語言編寫而成,而Java自身的跨平臺性,使得軟件的學習和使用更加方便。Burp Suite不像其餘的自動化測試工具,它須要你手工的去配置一些參數,觸發一些自動化流程,而後它纔會開始工做。html
Burp Suite可執行程序是java文件類型的jar文件,免費版的能夠從免費版下載地址進行下載。免費版的Burp Suite會有許多限制,不少的高級工具沒法使用,若是您想使用更多的高級功能,須要付費購買專業版。專業版與免費版的主要區別有
前端
本章主要講述Burp Suite的基本配置,包含以下內容:
java
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也能夠啓動。git
注意:your_burpsuite_path爲你Burp Suite所在路徑,burpSuite.jar文件名必須跟你下載的jar文件名稱一致github
若是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腳本的內容爲web
java -jar -Xmx2048M /your_burpsuite_path/burpsuite.jar
其中參數-Xmx指定JVM可用的最大內存,單位能夠是M,也能夠是G,若是是G爲單位的話,則腳本內容爲:正則表達式
java -jar -Xmx2G /your_burpsuite_path/burpsuite.jar
更多關於JVM性能調優的知識請閱讀 Oracle JVM Tuningchrome
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主要攔截http和https協議的流量,經過攔截,Burp Suite以中間人的方式,能夠對客戶端請求數據、服務端返回作各類處理,以達到安全評估測試的目的。
在平常工做中,咱們最經常使用的web客戶端就是的web瀏覽器,咱們能夠經過代理的設置,作到對web瀏覽器的流量攔截,並對通過Burp Suite代理的流量數據進行處理。
下面咱們就分別看看IE、Firefox、Google Chrome下是如何配置Burp Suite代理的。
當Burp Suite 啓動以後,默認分配的代理地址和端口是127.0.0.1 :8080,咱們能夠從Burp Suite的proxy選項卡的options上查看。如圖:
如今,咱們經過以下步驟的設置便可完成IE經過Burp Suite 代理的相關配置。
與IE的設置相似,在FireFox中,咱們也要進行一些參數設置,才能將FireFox瀏覽器的通訊流量,經過Burp Suite代理進行傳輸。詳細的步驟以下:
Google Chrome使用Burp Suite做爲代理服務器的配置步驟以下:
除了上述的三種經常使用的瀏覽器外,還有Safari瀏覽器也有很多的用戶在使用,其代理配置請點擊閱讀進行查看。
Burp Proxy 是Burp Suite以用戶驅動測試流程功能的核心,經過代理模式,可讓咱們攔截、查看、修改全部在客戶端和服務端之間傳輸的數據。
本章主要講述如下內容:
經過上一章的學習,咱們對Burp Suite代理模式和瀏覽器代理設置有了基本的瞭解。Burp Proxy的使用是一個按部就班的過程,剛開始使用時,可能並不能很快就獲取你所指望的結果,慢慢地當你熟悉了它的功能和使用方法,你就能夠用它很好地對一個產品系統作安全能力評估。
通常使用Burp Proxy時,大致涉及環節以下:
默認狀況下,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,從界面顯示來看,主要包括如下幾大板塊(涉及https的功能不包含在本章內容裏,後面會一章專門敘述):
客戶端請求消息攔截是指攔截客戶端發送到服務器端消息的相關配置選項,其界面以下:
主要包含攔截規則配置、錯誤消息自動修復、自動更新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相對應,就不在贅述,請參上一節的內容。
服務器返回消息修改是指自動修改服務器端返回消息的相關設置項。其界面以下:
自上而下,每個選擇項分別對應的功能是
<object>
標籤經過服務器返回消息修改可選擇項的設置,能夠方便滲透測試人員在安全評估過程當中突破原有的數據限制,更好、更快地檢測服務器端的安全性。
此項配置主要用來自動替換請求消息和服務器端返回消息中的某些值和文本,它與前文的規則的不一樣之處還在於支持正則表達式語言。
當點擊【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種方式。
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的歷史日誌功能和多種篩選過濾器讓咱們在使用中,能快速地查找須要的數據和關鍵信息,這些,都極大地幫助你提升了工做效率。
在前一章,咱們已經學習了HTTP消息如何經過Burp Proxy進行攔截和處理,本章咱們將繼續學習HTTPS協議消息的攔截和處理。
HTTPS協議是爲了數據傳輸安全的須要,在HTTP原有的基礎上,加入了安全套接字層SSL協議,經過CA證書來驗證服務器的身份,並對通訊消息進行加密。基於HTTPS協議這些特性,咱們在使用Burp Proxy代理時,須要增長更多的設置,才能攔截HTTPS的消息。
本章包含的主要內容有
咱們都知道,在HTTPS通訊過程當中,一個很重要的介質是CA證書,下面就咱們一塊兒來看看Burp Suite中CA證書的安裝。
通常來講,Burp Proxy代理過程當中的CA主要分爲以下幾個步驟(以win7下IE9爲例):
CA證書的卸載的一般有兩種方式,第一種方式在上一章節CA證書安裝中的第6步,找到須要卸載的證書,點擊【刪除】便可。咱們這裏主要描述第二種刪除方式,主要是爲了解決在第一種方式的基礎上刪除按鈕失效或者證書列表裏看不到的證書也一塊兒刪除的方法。
除了IE以外,其餘的瀏覽器如FireFox、Chrome、Sarifa等都證書的安裝和卸載基本相似,操做時能夠以IE的CA證書安裝做爲參考。
當咱們啓動Burp Suite時,默認會監聽本地迴路地址的8080端口,除此以外,咱們也能夠在默認監聽的基礎上,根據咱們本身的需求,對監聽端口和地址等參數進行自由設置。特別是當咱們測試非瀏覽器應用時,沒法使用瀏覽器代理的方式去攔截客戶端與服務器端通訊的數據流量,這種狀況下,咱們會使用本身的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證書鏈接到服務器胖客戶機應用程序的工做。
它有下列選項可供設置:
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 組件主要包含站點地圖、目標域、Target 工具三部分組成,他們幫助滲透測試人員更好地瞭解目標應用的總體情況、當前的工做涉及哪些目標域、分析可能存在的攻擊面等信息,下面咱們就分別來看看Burp Target的三個組成部分。
本章的主要內容有:
Target Scope中做用域的定義比較寬泛,一般來講,當咱們對某個產品進行滲透測試時,能夠經過域名或者主機名去限制攔截內容,這裏域名或主機名就是咱們說的做用域;若是咱們想限制得更爲細粒度化,好比,你只想攔截login目錄下的全部請求,這時咱們也能夠在此設置,此時,做用域就是目錄。整體來講,Target Scope主要使用於下面幾種場景中:
經過Target Scope 咱們能方便地控制Burp 的攔截範圍、操做對象,減小無效的噪音。在Target Scope的設置中,主要包含兩部分功能:容許規則和去除規則。
其中容許規則顧名思義,即包含在此規則列表中的,視爲操做容許、有效。若是此規則用於攔截,則請求消息匹配包含規則列表中的將會被攔截;反之,請求消息匹配去除列表中的將不會被攔截。
從上圖的添加規則對話框中咱們能夠看出,規則主要由協議、域名或IP地址、端口、文件名4個部分組成,這就意味着咱們能夠從協議、域名或IP地址、端口、文件名4個維度去控制哪些消息出如今容許或去除在規則列表中。
當咱們設置了Target Scope (默認所有爲容許),使用Burp Proxy進行代理攔截,在滲透測試中經過瀏覽器代理瀏覽應用時,Burp會自動將瀏覽信息記錄下來,包含每個請求和應答的詳細信息,保存在Target站點地圖中。
下圖所示站點地圖爲一次滲透測試中,經過瀏覽器瀏覽的歷史記錄在站點地圖中的展示結果。
從圖中咱們能夠看出,Site Map的左邊爲訪問的URL,按照網站的層級和深度,樹形展現整個應用系統的結構和關聯其餘域的url狀況;右邊顯示的是某一個url被訪問的明細列表,共訪問哪些url,請求和應答內容分別是什麼,都有着詳實的記錄。
基於左邊的樹形結構,咱們能夠選擇某個分支,對指定的路徑進行掃描和抓取。
同時,咱們也能夠將某個域直接加入 Target Scope中.
除了加入 Target Scope外,從上圖中,咱們也能夠看到,對於站點地圖的分層,能夠經過摺疊和展開操做,更好的分析站點結構。
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 Target中的站點信息,咱們能夠直接傳送到Burp Spider中進行站點信息的爬取。這一章咱們重點來學習Burp Spider的使用,主要包含兩個方面:
Burp Spider的功能主要使用於大型的應用系統測試,它能在很短的時間內幫助咱們快速地瞭解系統的結構和分佈狀況,下面咱們就先來看看Spider控制,
Spider控制界面由Spider 狀態和Spider 做用域兩個功能組成。
Spider 狀態除了顯示當前進度、傳輸狀況、請求隊列等統計信息外,還有Spider運行/暫停按鈕與清空隊列按鈕,分別用來控制Spider是否運行和隊列中的數據管理。而Spider 做用域是用來控制Spider的抓取範圍,從圖中咱們能夠看到有兩種控制方式,一種是使用上一章講的Target Scope,另外一種是用戶自定義。當咱們選中用戶自定義按鈕,界面改變成下面的樣子,以下圖所示。
此處用戶自定義做用域的配置與Target Scope 的配置徹底一致,具體使用方法請參數上一章Target Scope 的配置。
Spider可選項設置由抓取設置、抓取代理設置、表單提交設置、應用登錄設置、蜘蛛引擎設置、請求消息頭設置六個部分組成。
Burp Scanner的功能主要是用來自動檢測web系統的各類漏洞,咱們能夠使用Burp Scanner代替咱們手工去對系統進行普通漏洞類型的滲透測試,從而能使得咱們把更多的精力放在那些必需要人工去驗證的漏洞上。
在使用Burp Scanner以前,咱們除了要正確配置Burp Proxy並設置瀏覽器代理外,還須要在Burp Target的站點地圖中存在須要掃描的域和URL模塊路徑。以下圖所示:
當Burp Target的站點地圖中存在這些域或URL路徑時,咱們才能對指定的域或者URL進行全掃描或者分支掃描。下面咱們就來總體的學習一下,一次完整的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 會嚮應用發送新的請求並經過payload驗證漏洞。這種模式下的操做,會產生大量的請求和應答數據,直接影響系統的性能,一般使用在非生產環境。它對下列的兩類漏洞有很好的掃描效果:
對於第一類漏洞,Burp在檢測時,會提交一下input域,而後根據應答的數據進行解析。在檢測過程當中,Burp會對基礎的請求信息進行修改,即根據漏洞的特徵對參數進行修改,模擬人的行爲,以達到檢測漏洞的目的。
對於第二類漏洞,通常來講檢測比較困難,由於是發生在服務器側。好比說SQL注入,有多是返回數據庫錯誤提示信息,也有多是什麼也不反饋。Burp在檢測過程當中,採用各個技術來驗證漏洞是否存在,好比誘導時間延遲、強制修改Boolean值,與模糊測試的結果進行比較,已達到高準確性的漏洞掃描報告。
當使用被動掃描模式時,Burp不會從新發送新的請求,它只是對已經存在的請求和應答進行分析,這對系統的檢測比較安全,尤爲在你受權訪問的許可下進行的,一般適用於生成環境的檢測。通常來講,下列這些漏洞在被動模式中容易被檢測出來:
雖然被動掃描模式相比於主動模式有不少的不足,但同時也具備主動模式不具有的優勢,除了前文說的對系統的檢測在咱們受權的範圍內比較安全外,當某種業務場景的測試,每測試一次都會致使業務的某方面問題時,咱們也能夠使用被動掃描模式,去驗證問題是否存在,減小測試的風險。
當咱們對一個系統進行掃描完畢後,一般須要生成掃描報告,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 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有主動掃描和被動掃描兩個掃描方式,在Options子選項卡中,主要是針對這兩種掃描方式在實際掃描中的掃描動做進行設置。具體的設置包含如下部分:
對於以上的攻擊插入點,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)
在主動掃描過程當中,你能夠根據你的掃描時間、關注的重點、可能性存在的漏洞類型等狀況,選擇不一樣的掃描範圍。這裏可選擇的掃描範圍有:
5.被動掃描範圍設置(Passive Scanning Areas)
由於被動掃描不會發送新的請求,只會對原有數據進行分析,其掃描範圍主要是請求和應答消息中的以下參數或漏洞類型:Headers、Forms、Links、Parameters、Cookies、MIME type、Caching、敏感信息泄露、Frame框架點擊劫持、ASP.NET ViewState 。
Burp Intruder做爲Burp Suite中一款功能極其強大的自動化測試工具,一般被系統安全滲透測試人員被使用在各類任務測試的場景中。本章咱們主要學習的內容有:
在滲透測試過程當中,咱們常用Burp Intruder,它的工做原理是:Intruder在原始請求數據的基礎上,經過修改各類請求參數,以獲取不一樣的請求應答。每一次請求中,Intruder一般會攜帶一個或多個有效攻擊載荷(Payload),在不一樣的位置進行攻擊重放,經過應答數據的比對分析來得到須要的特徵數據。Burp Intruder一般被使用在如下場景:
一般來講,使用Burp Intruder進行測試,主要遵循如下步驟:
以上這些,是Burp Intruder一次完成的操做步驟,在實際使用中,根據每個人的使用習慣,會存在或多或少的變更。而每個環節中涉及的更詳細的配置,將在接下來的章節中作更細緻的闡述。
在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 positions)選項卡的設置界面:
從上圖中咱們能夠看出,Payload位置的設置是基於Http請求的原始消息做爲母板,使用一對 §字符來標記出Payload的位置,在這兩個號直接包含了母板文本內容。 當咱們已經把一個Payload在請求消息的特殊位置上時標明後,發起攻擊時,Burp Intruder 就把一個Payload值放置到給出的特殊位置上,替換 §符號標示的整個位置。如上圖中的參數id後面的 §符號之間的標明的是Payload位置1,name後面的 §符號之間標明的是Payload位置2,這個值對應於Payload設置中的Payload set的值。
咱們能夠在消息編輯器中間對Payload位置進行編輯,它主要是由右側的四個按鈕來控制的。
【Auto §】——對消息內容中可能須要標誌的參數作一個猜想,標誌爲Payload位置,自動設置完以後再作人工的選擇,肯定哪些位置是須要傳入Payload的。目前Burp支持自動選擇的參數類型有:
1.URL請求參數
2.Body參數
3.cookie參數
4.複合型參數屬性,好比文件上傳時候的文件名
5.XML數據
6.JSON數據
雖然Burp默認是支持自動標誌這些類型的參數做爲Payload位置,但若是是針對於像XML或JSON的節點屬性值的,仍是須要手工指定。
【Refresh】——刷新消息內容中帶有顏色的部分。
在消息編輯器的上方,有一個下拉選擇框,攻擊類型(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。
可選項設置主要包括請求消息頭設置、請求引擎設置、攻擊結果設置、grep match, grep extract, grep payloads,以及重定向設置。在使用中,你能夠在攻擊前進行設置,也能夠在攻擊過程當中作這些選項的調整。
請求引擎設置(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如何處理重定向,在實際使用中每每是必須遵循重定向,才能實現你的攻擊目的。例如,在密碼猜想攻擊,每次嘗試的結果多是密碼錯誤會重定向響應到一個錯誤消息提示頁面,若是密碼正確會重定向到用戶中心的首頁。
但設置了重定向也可能會遇到其餘的問題,好比說,在某些狀況下,應用程序存儲您的會話中初始請求的結果,並提供重定向響應時檢索此值,這時可能有必要在重定向時只使用一個單線程攻擊。也可能會遇到,當你設置重定向,應用程序響應會重定向到註銷頁面,這時候,按照重定向可能會致使您的會話被終止時。
因其設置選項跟其餘模塊的重定向設置基本一致,此處就再也不重敘。
一次攻擊的發起,一般有兩種方式。一種是你在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 Suite中一款手工驗證HTTP消息的測試工具,一般用於屢次重放請求響應和手工修改請求消息的修改後對服務器端響應的消息分析。本章咱們主要學習的內容有:
在滲透測試過程當中,咱們常用Repeater來進行請求與響應的消息驗證分析,好比修改請求參數,驗證輸入的漏洞;修改請求參數,驗證邏輯越權;從攔截歷史記錄中,捕獲特徵性的請求消息進行請求重放。Burp Repeater的操做界面以下圖所示:
請求消息區爲客戶端發送的請求消息的詳細信息,Burp Repeater爲每個請求都作了請求編號,當咱們在請求編碼的數字上雙擊以後,能夠修改請求的名字,這是爲了方便多個請求消息時,作備註或區分用的。在編號的下方,有一個【GO】按鈕,當咱們對請求的消息編輯完以後,點擊此按鈕即發送請求給服務器端。服務器的請求域能夠在target處進行修改,如上圖所示。
應答消息區爲對應的請求消息點擊【GO】按鈕後,服務器端的反饋消息。經過修改請求消息的參數來比對分析每次應答消息之間的差別,能更好的幫助咱們分析系統可能存在的漏洞。
在咱們使用Burp Repeater時,一般會結合Burp的其餘工具一塊兒使用,好比Proxy的歷史記錄,Scanner的掃描記錄、Target的站點地圖等,經過其餘工具上的右擊菜單,執行【Send to Repeater】,跳轉到Repeater選項卡中,而後纔是對請求消息的修改以及請求重放、數據分析與漏洞驗證。
與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 Suite中一款用於檢測數據樣本隨機性質量的工具,一般用於檢測訪問令牌是否可預測、密碼重置令牌是否可預測等場景,經過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.當我再次使用時,直接加載數據進行分析便可。
分析可選項設置的目的主要是爲了控制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 Suite中一款編碼解碼工具,它能對原始數據進行各類編碼格式和散列的轉換。其界面以下圖,主要由輸入域、輸出域、編碼解碼選項三大部分組成。
輸入域即輸入須要解碼的原始數據,此處能夠直接填寫或粘貼,也能夠經過其餘Burp工具的上下文菜單中【Send to Decoder】;輸出域即對輸入域進行解碼的結果顯示出來。不管是輸入域仍是輸出域都支持文本與Hex兩種格式,其中編碼解碼選項中,由解碼選項(Decode as)、編碼選項(Encode as)、散列(Hash)三個構成。實際使用中,能夠根據場景的須要進行設置。對於編碼解碼選項,目前支持URL、HTML、Base6四、ASCII、16進制、8進制、2進制、GZIP共八種形式的格式轉換,Hash散列支持SHA、SHA-22四、SHA-25六、SHA-38四、SHA-5十二、MD二、MD5格式的轉換,更重要的是,對於同一個數據,咱們能夠在Decoder的界面,進行屢次編碼解碼的轉換。以下圖所示: