使用FreeHttp任意篡改http報文 (FreeHttp使用及實現說明)

本文轉自:https://www.cnblogs.com/lulianqi/p/10428551.htmlhtml

前言

FreeHttp是一個Fiddler插件藉助FreeHttp您可按照您本身的設定修改請求或響應報文
這對測試及調試都很是有用
好比您發現線上頁面js文件錯誤,直接使用規則替換新的js文件您能夠在不對線上服務作任何改動的狀況下直接在線上驗證
一樣在發現服務接口數據不符合預期時也能夠直接修改驗證,甚至能夠清除手機瀏覽器或微信服務號的登錄狀態
但願在您瞭解其基本功能及工做原理後,能夠實際工做中爲您提供便利
 

FreeHttp起始

現在互聯網或IT行業幾乎跟HTTP已經分不開了,系統與系統之間的聯繫至關一部分都須要藉助HTTP,在平時的工做中(特別是測試工做)漸漸的會發現本身除了對抓取HTTP報文有需求,不少時候須要篡改報文輔助測試或調試。
Fiddler實際已經提供斷點,AutoResponder及FiddlerScript 功能能夠直接或間接實現報文篡改功能,不過使用過程當中會發現,他們在不少狀況下使用不是很方便甚至達不到個人需求
爲了知足本身的一些特定需求,藉助Fiddler擴展接口本身慢慢的爲本身編寫了插件,後來插件功能愈來愈多,本身就萌生了把功能作成通用的形式或許能夠給其餘同窗提供幫助(也就成爲了FreeHttp的雛形)

 

FreeHttp 插件安裝

1:您的計算機須要已經安裝Fiddler (如未安裝,請至官網下載安裝 http://docs.telerik.com/fiddler/configure-fiddler/tasks/configurefiddlergit

2:進入Fiddler安裝目錄的Scripts目錄下,將FreeHttp.dll複製到該目錄下  (下載請至:https://files.cnblogs.com/files/lulianqi/FreeHttp.zip   解壓可獲得 FreeHttp.dll  )github

3:重啓Fiddler便可在面板中出現 FreeHttp 標籤web

 

FreeHttp 基本界面

基本操做界面以下圖,主要分爲5個部分
 
  1. Session 匹配規則編輯區『Url Filter』
  2. Htpp 請求或響應篡改規則編輯區
  3. 規則編輯控制條
  4. http session 捕獲/篡改或規則執行日誌
  5. 已建立http篡改規則列表

         當請求發出或接收到響應時,freehttp會在篡改規則列表中匹配篡改規則(匹配使用Url Filter中的內容),若是匹配成功即執行http報文的篡改(篡改使用規則編輯區內容)正則表達式

 
            如上圖您能夠簡單調整各顯示區域的佈局
 
 
備註:   因爲本文篇幅較長,若是您當前時間不充裕或暫時不打算查看 FreeHttp的詳細功能,建議您直接閱讀第6章節【六:快速入門】,第7章節【七:簡單實踐】(這2章節有能夠幫您快速瞭解FreeHttp的基本功能)
            若是您對FreeHttp的代碼實現感興趣,或您打算修改FreeHttp的功能,您能夠在末尾章節【實現及源碼】找到相關內容(源代碼地址及工程結構簡介)
 
 
 

一:規則匹配區

 

 

1.1:『get http sesion in left session list』

表示從fiddler Session列表獲取Session信息
點擊此圖標會將您選中的session的url自動填充到urlfilter輸入框中, 並將該session的request及response信息填入下方Http篡改規則的『Request Replace』及『Response Replace』中方便篡改規則的編輯
(如上圖:選擇fiddler默認更新session,點擊獲取按鈕,黃色區域即爲獲取的信息)
 

1.2:『select url filter method』

表示url匹配方式(匹配後方文本框中內容),支持Contain,StartWith,Is,Regex,AllPass
  • Contion:噹噹前Http請求session url包含指定值時匹配經過。
  • StartWith:噹噹前Http請求session url以指定值開始時匹配經過。
  • Is:噹噹前Http請求session url與指定值徹底一致時匹配經過。
  • Regex:噹噹前Http請求session url 經過指定正則匹配時匹配經過。(如[「^https://www.bing.cn/js/page.\S*?.js\b」該正則匹配表示以「https://www.bing.cn/js/page.」開頭並以「.js」結尾而且中間含隨機版本的js請求url)
  • AllPass:對任意Http請求session url匹配經過。(當您須要爲全部經過fiddler的請求都進行指定規則的篡改時,好比爲全部請求添加標記head頭,或設置禁用驗證緩存時可能會須要使用到AllPass匹配方式)
 
(如上圖:當鼠標懸停該區域,會有匹配方式提示出現)
 

1.3:『adit advanced http filter』

點擊此圖標能夠進行http篡改匹配規則的高級匹配
包括對request 對請求頭及請求實體的匹配檢查
若是前面的Url Filter 選項已經能幫助您篩選目標http請求,您不用再設置該項
默認狀態下『adit advanced http filter』圖標顯示爲黑色,表示沒有對advanced http filter進行過設置
若是您對當前匹配規則的advanced http filter已經進行過設置,該圖標會顯示爲藍色
點擊該圖標便可在彈出窗口中設置 advanced http filter
如上圖 advanced http filter分爲4部分
1:Url Filter 部份內容與前面的Url Filter 徹底一致(這裏不在單獨說明)
2:Head Filter 部分能夠幫你設置head頭篩選,點擊『+』彈出操做框按提示輸入Key於Value(表示被匹配http請求必須知足,請求頭中必須含有Key值請求頭,而且該請求頭的內容必須含有Value值)
點擊目標控制區域『+』彈出添加對話框進行添加
點擊目標控制區域『-』 能夠刪除已經添加但再也不須要的規則(不選擇任何指定item則移除當前全部)
雙擊任意條目彈出編輯框能夠對已經添加條目進行編輯操做
3:HTTP Body Filter 部分的邏輯於Url Filter 維持一致,惟一不一樣的是此處的篩選條件是請求的body
4:Rule Alias 部分用於設置該規則的別名 (該別名會顯示在後面 『Tamper Rule』篡改規則列表區)
注意以上2,3,4都不是必須項若是不須要能夠不用填寫
 
 

1.4:『new or edit rule』

在建立模式確認建立新規則
在編輯模式確認保存當前規則
該按鈕與下方『規則編輯控制條』中確認按鈕意義一致
 
 

二:請求或響應篡改規則編輯區域

 
HTTP篡改區有4個tab分別是 請求修改『Request Modific』;請求替換『Request Replsce』;響應修改『Response Modific』;響應替換『Response Replace』
經過設置這4類篡改規則您幾乎能夠對指定Http請求的request或response進行任意的篡改,使它變爲您須要的樣子
篡改還包括對文件及動態參數化及外部文件數據源的支持
 

2.1:『Request Modific』

『Request Modific』能夠完成對http請求的篡改,請求修改按HTTP自身結構分爲4塊
分別是對請求url的修改,對請求頭的移除,對請求頭的添加,對請求實體的修改
 

2.1.1:請求行uri 修改 『Uri Modofic』

該編輯區用於控制修改匹配http request的url
不輸入任何值,則表明不修改該項
第一個文本框輸入須要替換的內容,第二個文本框輸入替換以後的內容
注意:該替換規則將替換目標中全部匹配字符串(若是發現多處匹配,將都被替換)
若是第一個文本框置空,僅在第二個文本框中輸入內容,則表明替換請求行的整個uri
如請求行是 GET https://www.fiddler2.com/UpdateCheck.aspx?isBeta=False HTTP/1.1 ,在第一個文本框中輸入""(置空不輸入),在第二個文本框中輸入「http://test.com」
若是請求『Url Filter』規則匹配,請求在發送前請求行將被篡改成 GET http://test.com HTTP/1.1
如上圖,在第一個文本框中輸入"isBeta=False",在第二個文本框中輸入「isBeta=true」
若是請求『Url Filter』規則匹配,若請求行是 GET https://www.fiddler2.com/UpdateCheck.aspx?isBeta=False HTTP/1.1 ,則Url Modific執行(由於url含有「isBeta=False」),請求在發出前,請求行將被篡改成 GET https://www.fiddler2.com/UpdateCheck.aspx?isBeta=true HTTP/1.1
 

2.1.2:請求頭heads移除『Head Modific』『Remove Head』

該編輯區用於控制修改匹配http request的head頭,刪除指定request head頭
點擊目標控制區域『+』彈出添加對話框進行添加
點擊目標控制區域『-』 能夠刪除已經添加但再也不須要的head移除規則(不選擇任何指定item則移除當前全部)
雙擊任意條目彈出編輯框能夠對已經添加條目進行編輯操做
(如上圖點擊添加,彈出窗口進行添加,或雙擊任意item彈出該窗口進行編輯)
以上『Remove Head』設置表示移除請求頭中的Pragram,Cache-Contorl,If-None-Match,If-Modified-Since請求頭

 

2.1.3:請求頭heads添加『Head Modific』『Add Head』

該編輯區用於控制修改匹配http request的head頭,添加指定request head頭
點擊目標控制區域『+』彈出添加對話框進行添加
點擊目標控制區域『-』 能夠刪除已經添加但再也不須要的head添加規則(不選擇任何指定item則移除當前全部)
雙擊任意條目彈出編輯框能夠對已經添加條目進行編輯操做
 
(如上圖點擊添加彈出窗口進行添加,或雙擊任意item彈出該窗口進行編輯)
以上『Add Head』設置表示添加請求頭請求頭Pragma: no-cache , Cache-Control: no-cache (由於在『Remove Head』中也有Pragme請求頭,因此實際含義是修改Pragme請求頭爲no-cache)
 

2.1.3備註

  • 關於『Remove Head』
由於RFC@2616 請求頭中頭域名稱不區分大小寫,因此host與hoST的意義是同樣的,一旦規則匹配將會移除請求頭中的host頭
  • 關於『Add Head』
添加請求頭容許添加2個同名域頭,好比您能夠同時添加Accept-Encoding: gzip 和Accept-Encoding: deflate 這2個頭會分別添加到請求頭域(即便使用同樣的頭域名稱)
注意因爲同名頭域並不會相互覆蓋,因此若是你想實現指定請求頭的修改功能,須要先刪除指定頭域,再添加該頭域
好比您須要將Pragma:xxx 改成Pragma: no-cache,就須要先添加一個Remove Head測試規則Pragma,而後添加一個頭域修改規則Pragma: no-cache
  • 關於請求或響應篡改規則編輯區域其餘相似『Add Head』的操做規則
基本操做邏輯維持一致
點擊『+』添加項
點擊『-』刪除選定項(未選定任何項刪除所有)
雙擊任意項爲編輯該項
 
 
2.1.4:請求體Body修改『Body Modific』
若是您對請求中含有Body,您可能也會有對請求體body的修改的需求
Body Modific的邏輯與Uri Modific基本維持一致,不過同時支持regex正則替換
不輸入任何值,則表明不修改該項
第一個文本框輸入須要替換的內容,第二個文本框輸入替換以後的內容
當第一個文本框以<regex>開頭時則表示啓用正則替換,後面的內容爲查找替換的的正則表達式
如第一個文本框中輸入"<egex>nloginpwd=.*?&"(不包含引號),第二個文本框中輸入「nloginpwd=123456&」
該正則替換規則表示將請求體Body中全部以「nloginpwd=」開頭,以「&」結尾的文本替換爲「nloginpwd=123456」
如上圖,在第一個文本框置空,在第二個文本框中輸入「test」
若是請求『Url Filter』規則匹配,Http請求body將被替換爲「test body」
注意這種設置即便原始body爲空也會進行替換(實際上GET等請求是不含有請求實體的,此處僅爲演示)
 

2.2:『Request Replace』

『Request Replace』能夠完成對http請求的總體替換
Request Replace是http請求的另外一種篡改模式,他不關心匹配請求的原始request內容,直接對整個請求作替換操做
Request Replace 對替換規則的編輯分爲兩種方式,輔助模式及Raw模式
爲了方便您建立替換規則,『Request Replace』按http請求結構分爲3部分,請求行,請求頭請求體,及Raw描述切換(不使用格式輔助,進入Raw編輯進行編輯)
 

2.2.1 『Start Line』編輯替換請求行

請求行的編輯按請求行的規則分爲
對請求方法的編輯(能夠進行下拉輔助編輯,或手動輸入自定義方法)
對url的編輯(注意請保持url的完整性)
對http協議版本的編輯(能夠進行下拉輔助編輯,或手動輸入自定義方法)
 
 

2.2.2 『Request Heads』編輯替換請求頭

請求替換中對請求頭的編輯與【2.1.3】中設置請求頭相似,使用一樣的方式進行配置編輯(此處再也不重複說明)
此處的請求頭將與上面『Start Line』一塊兒用於總體替換

 

2.2.3 『Request Body』編輯替換請求體

請求體的替換的編輯基本功能十分便捷,您只須要在圖中高亮部分填入您想要的request body正文便可
若是您的body正文是二進制的數據,或是一個須要上傳的文件,您能夠直接在此處添加本地文件
編輯框單機鼠標右鍵,在彈出菜單中選擇『add file』
選擇計算機中本地文件文件
如上圖選擇文件後「<<replace file path>>C:\Users\administer\Pictures\3613e290-8028-4ddc-946c-b89c67f4f31a.jpg」將會被添加至編輯框
表示3613e290-8028-4ddc-946c-b89c67f4f31a.jpg該文件將直接做爲request的請求實體進行替換
您也能夠按照格式約定手動添加文件(以「<<replace file path>>」開頭,後接文件路徑)
注意:只有以<<replace file path>>開頭才表示文件模式(「data<<replace file path>>C:\test.jpg」這種數據將不會被看成文件處理)
關於『add Parameter』添加參數化數據
您能夠在您須要的任意地方右鍵選擇『add Parameter』添加您想要的靜態化數據
詳細使用方法請查看【八:參數化數據設置】(不瞭解參數化數據的設置並不會影響您使用freehttp的主要功能)

 

2.2.4 『Raw Mode』切換原始數據視圖

若是您熟悉Http原始報文,您能夠點擊下圖中的圖標進入raw mode,對將要替換的原始報文進行編輯
 
進入raw mode能夠直接編輯(若是您使用『get http sesion in left session list』獲取過session信息,這裏會提早填入目標http的request報文方便您的編輯)
您不用擔憂您輸入的錯誤的http格式會影響替換,若是使用『raw mode』在您編輯或新增完成時,系統會檢查你的輸入,若是格式有誤,會給出明確提示告訴您什麼地方不符合標準規範(標準規範請參見RFC2616)
raw mode 支持上文request replace的所有功能,包括【八:參數化數據設置】會介紹的參數化數據  
在raw mode您一樣可使用文件替換request body,替換方式與【2.2.3】中的問題替換基本維持一致
須要注意的是,只有request body才能被替換爲文件
如上圖若是您已經有body 內容爲test data,則不能同時添加文件body
 

2.2.4備註

在右鍵添加文件時,同時能夠看到右鍵菜單中有『anto Content-Length』,若是勾選該項在你建立或保存當前規則時會自動計算Body長度併爲請求添加Content-Length頭。
在你點擊建立或保存按鈕時,『Request Replace』Tab當前停在raw mode模式 即保存raw mode 數據,停在輔助模式則使用輔助模式的數據
 

2.3:『Response Modific』

『Response Modific』能夠完成對http響應的任意篡改,請求修改按HTTP自身結構分爲3塊,分別是對響應頭的移除,對請響應的添加,對響應實體的修改
『Response Modific』的編輯及執行模式與『Response Modific』基本維持一致,不一樣的是在『Response Modific』不能對響應行及響應狀態碼進行篡改(由於對狀態碼的修改意味着對整個響應的徹底修改,若是須要修改狀態碼請使用後面的『Response Replace』)
 
 

2.3.1:響應頭heads移除『Head Modific』『Remove Head』

該編輯區用於控制修改匹配http response的head頭,刪除指定response head頭
該項編輯邏輯與【2.1.2】中對請求頭的移除是一致的,這裏再也不重複說明
 

2.3.2:響應頭heads添加『Head Modific』『Add Head』

該編輯區用於控制修改匹配http response的head頭,添加指定response head頭
該項編輯邏輯與【2.1.3】中對請求頭的添加是一致的,這裏再也不重複說明
 
 

2.3.3:響應體Body修改『Body Modific』

若是您的響應中含有body,您可能也會有對響應body的修改的需求
一樣支持徹底覆蓋,替換,正則替換
該項編輯邏輯與【2.1.4】中對請體的修改是一致的,這裏再也不重複說明
 
如上圖設置則表示爲匹配的http響應添加一個Set-Cookie頭,內容爲UM_distinctid=167,當瀏覽器接收到這個被篡改過的響應頭後,會爲該域名添加名爲UM_distinctid的cookie,若是已有同名cookie則會直接覆蓋
 
 

2.4:『Response Replace』

『Response Replace』能夠完成對http響應的總體替換
Response Replace是http響應的另外一種篡改模式,他不關心匹配請求的原始response內容,直接對整個響應作替換操做
Response Replace 對響應的替換直接使用Raw模式,不過爲了方便替換提供了一組標準響應返回的模板
Response Replace 按編輯功能分爲3部分,響應Raw內容編輯,模板選擇,Response Direct選擇

 

2.4.1 響應Raw原始報文編輯

在此Tab能夠直接編輯替換用的Raw原始報文(若是您使用『get http sesion in left session list』獲取過session信息,這裏會提早填入目標http的response報文方便您的編輯)
您不用擔憂您輸入的錯誤的http格式會影響替換,若是使用『response replace』在您保存或新建時系統會檢查你的輸入,並給出明確提示告訴您什麼地方不符合標準規範(標準規範請參見RFC2616)
與【2.2.4】 請求『Raw Mode』替換同樣,支持文件及參數化數據,除報文要求的格式外,其餘編輯邏輯與【2.2.4】中規則維持一致,此處再也不重複說明
 

2.4.2『Select Replace Template』選擇模板

若是您須要本身建立response響應內容,您可使用模板輔助您的編輯,模板包含大多數常規響應的基本格式
如上圖下拉選擇您想要的模板便可,上圖中選擇了[HTTP/1.1 200 OK]的模板,模板內容便是一個常規Http 200 返回的例子,您能夠直接在例子上進行修改
 

2.4.3『Response Direct』直接返回響應

該選項用於控制response返回時機,當『Url Filter』匹配到http請求後,同時該篡改規則爲『Response Replace』時,可使用該項設置請求是否直接返回
當『Response Direct』被勾選選時,feddler將不會把請求發送到目標服務器,而是使用Response Replace裏的resonse直接返回,即客戶端發送請求後就會當即接收到您自定義的響應,這種模式對於實際請求是不存在的或暫時不能連通的狀況是十分必要(好比您想要使用暫時未開發好的接口,這時就須要該選項mock接口),同時您能夠設置接口的執行時間在後面【3.3】『set response latency』 會介紹如何爲響應設置指定響應時間
當『Response Direct』未被勾選時,則使用常規請求路徑,請求會被髮送至服務器(即便服務的返回並不會被使用),在服務返回響應結果後,執行替換操做 (默認不勾選)
 
 

三:規則編輯控制條及常規設置編輯區域

規則控制編輯條由3部分組成如上圖1,2,3,4組成的規則控制,5快速規則編輯,6篡改工具及常規設置
 

3.1『affirm rule』確認建立規則或保存規則修改

該按鈕的功能與【1.4】『new or edit rule』維持一致
在建立模式確認建立新規則
在編輯模式確認保存當前規則
如上圖當年點擊確認(黃色標記區域)時,即會建立能編輯的篡改規則
請注意上方『url Filter』右側文字提示(New Mode 表示如今處於建立模式)會顯示當前模式
還有一點須要說明當前篡改規則編輯區域停留在哪一種編輯模式,便是對哪一種規則的保存(『Request Modific』『Request Replsce』『Response Modific』『Response Replace』)
單個規則僅包含一種篡改規則,若是您須要對同一個請求同時執行多個篡改,您能夠對其建立多個篡改規則(實際應用中這種場景是存在的)
若是當前建立的規則是『Request Modific』或『Request Replsce』,建立完成的規則會出如今『Request Rule』列表中,若是是『Response Modific』或『Response Replace』,建立完成則會出如今『Response Rule』中
完成建立後,下方日誌會有相應記錄,並清空當前編輯區域(圖中編輯區域沒有清空僅爲演示,實際使用中編輯區數據將徹底被清除)
當您點擊確認時系統會檢查您編輯的規則,若是有不符合要求的地方會有相應提示,並在出現錯誤的編輯的區域進行短期的高亮顯示以提示 (一般若是是新規則會在添加在規則類表末尾,並有短期高亮顯示進行提示)
 

3.2『cancel edit』取消

『cancel edit』功能相對簡單,僅用於清除編輯區域保存的信息
在建立模式直接清除信息,在編輯模式能夠取消對當前規則的編輯狀態
 

3.3『set response latency』 設置響應延時

『set response latency』可用於設置『Response Rule』的響應延遲(『Response Modific』及『Response Replace』爲『Response Rule』)
如上圖該圖標按鈕有3種狀態(can set , unable set,is seded)
1.can set:延時設置對當前篡改規則爲可設置狀態,此時點擊該圖標即彈出設置框。
2.unable set :延時設置對當前篡改規則爲不可設置狀態,此時該圖標不能點擊,由於響應延時是針對http response的延時,即該設置對『Request Modific』『Request Replsce』是無效的
3.is seted:第3種狀態是已經設置過延時的狀況,如圖設置的數值將會直接顯示在剛剛圖標的位置。(這個時候也能夠點擊該數值進行修改)
設置窗口如上圖,您直接填入數值便可(單位爲毫秒),若是填0或空則表示不設置延時
 

3.4『set parameter pick info』設置參數化數據獲取規則

『set parameter pick info』用於在原始請求或響應中捕獲初始化數據(對現有參數化數據作添加或修改操做)
該圖標有2種狀態含義分別是
1:該篡改規則未設置任何參數捕獲規則
2:該篡改規則至少已經設置一條參數捕獲規則
這兩種狀態下均可以點擊圖標直接進入編輯框,若是已經有設置過的規則,已有規則會在編輯框中直接加載
詳細使用方法請查看【八:參數化數據設置】(不瞭解參數化數據的設置並不會影響您使用freehttp的主要功能)
 

3.5『Quick Rule』快速規則

當前版本共有6個快速規則,幫助您快速完成篡改規則的設置
 

3.5.1『disable cache』

該quick rule針對Request Modific,能夠爲匹配規則的請求去除條件緩存並強制服務器不要使用緩存
如上圖使用該quick rule後會在『Request Modific』中『Head Modific』直接添加預設的值,這時您直接點擊確認便可用快速完成一個Request Rule的建立
 

3.5.2『add cookie 』

該quick rule針對Request Modific,能夠爲匹配規則的請求添加指定cookie
選擇項後彈出如上圖對話框,直接輸入您須要設置的cookie便可,(注意cookie的格式 key=value )
 

3.5.3『delete cookie』

該quick rule針對Response Modific,能夠爲匹配規則的響應添加Set-Cookie(經過設置指定cookie當即過時,從而實現刪除客戶端cookie的功能)
選擇項後彈出如上圖對話框,在Name處輸入你想要刪除cookie的名稱(同時爲了讓瀏覽器準肯定位到您要刪除的cookie,你還須要注意修改Domain及Path爲正確的值,通常狀況下Domain爲當前網站域名,Path爲/)
 

3.5.4『set client cookie』

該quick rule針對Response Modific,能夠爲匹配規則的響應添加指定Set-Cookie,設置客戶端cookie (這裏是經過Set-Cookie完成對客戶端cookie的效果,好比在手機瀏覽器,或某些軟件的內置web瀏覽器並無提供調試模式,這個時候Set-Cookie將是不錯的解決方案)
選擇項後彈出如上圖對話框,按提示輸入指定值便可
 

3.5.5『copy session cookies』

該quick rule針對針對Response Modific,能夠快速將指定session的全部cookies快速的設置到客戶端另外一個域下(該功能可讓您在多個瀏覽器,甚至多個設備,多個域名下共享同一份cookie,這在調試或測試中跳過受權會很是有效)
如上圖要使用該功能,您須要先在Filddler左側Session列表選擇您須要複製cookies的源請求(圖中選擇的是github.com/lulianqi/FreeHttp),選中指定session後點擊copy session cookies便可以看到在Heads Modific的Add Head編輯框自動添加了來自github的cookie信息(該規則會爲匹配的請求添加Set-Cookies從而達到複製效果)
 

3.5.6『add UserAgent』

該quick rule針對Request Modific,能夠爲匹配規則的請求添加指定UserAgent
如上圖該項相對簡單,直接填入您須要的UserAgent便可
 

3.6『Modific Tool』篡改工具及常規設置

當前版本共有4個工具項,方便您的使用或提供其餘設置功能

3.6.1『show selected session stream』

該工具能夠將您選擇的session以RAW的模式顯示在一個新的窗口(該窗口一直頂層顯示,但不影響您在主窗口下的操做),您在建立篡改規則的同時可使用該窗口查看session信息而不用切換Tab(您也能夠直接在session列表中選中session拖動到編輯區域,raw形式的報文一樣會顯示在日誌區,但不會打開新的窗口 )
如上圖在fiddler左側session列表選擇任意請求,點擊show selected session stream將會彈出新的獨立窗口以顯示您選擇的session的原始報文
 

3.6.2『http tamper setting』

該項提供一些對FreeHttp插件的基本設置
  • is only match fist tamper rule: (默認是)是否僅執行第一個匹配成功的篡改規則(由於您能夠對同一個請求有多個篡改規則,您能夠經過此選項控制是否執行多個篡改規則)
  • is skip tls handshake:(默認是)是否對TLS握手包進行匹配(除非您須要調試TLS握手,建議您維持默認設置)
  • is default enable tamper rule:(默認否)是否默認啓用規則匹配(在『Request Rule』及『Response Rule』都有獨立啓用開關,該選項用於控制軟件啓動時的默認狀態)
 

3.6.3『parameter data manage』參數化數據管理器

該項提供對FreeHttp的參數化數據的集中管理
選擇該項後彈出層管理器窗口,您能夠在管理器中對參數進行新增,修改,測試等操做
後面【八:參數化數據設置】會詳細介紹參數化數據的使用,這裏暫不具體說明
 

3.6.4『issues and suggest』

點擊該選會使用您的默認瀏覽器打開問題提交頁,您能夠在該頁提交您的問題及意見(在此處提交問題可能須要您擁有github賬號,若是不方便登陸能夠直接發送郵件至 mycllq@hotmail.com提交您的問題及建議)
 
 

四:『Execution Log』執行日誌

該區域僅對篡改規則的操做及執行日誌進行顯示
日誌統一格式以數據開頭,並用顏色區分錯誤,提示及信息日誌
 
 
 

五:『Tamper Rule』篡改規則列表

『Tamper Rule』篡改規則主要集中顯示及管理您已經建立的規則,您能夠在這裏設置須要生效的規則,刪除或修改已有規則,對規則排序等操做
列表分爲2部分(這2部分的操做邏輯都是一致,僅是存儲的規則類型不同)
  • 上部列表爲『Request Rule』請求篡改規則(由『Request Modific』,以編輯圖標顯示及『Request Replsce』以替換圖標顯示組成)
  • 下部列表爲『Request Rule』響應篡改規則(由『Response Modific』,以編輯圖標顯示及『Response Replace』,以替換圖標顯示組成)
 

5.1 Tamper Rule控制選項

Tamper Rule控制選項主要由2部分組成
位於右上角的控制欄,從左至右分別是『+』添加,『-』刪除,『啓用』控制
點擊添加:編輯面板會直接切換至『Request Modific』提示您進行編輯(若是是在『Response Rule』上點擊添加編輯面板則會切換至『Response Modific』)
點擊刪除:刪除選中Rule,若是沒有選擇任何Rule則會向您詢問是否刪除所有Rule
啓用控制:Request Rule與Response Rule的啓用控制是獨立的,您能夠分別設置他們的啓用狀態,只有當您選擇啓用後,Fillder纔會匹配列表中處於Checked狀態的規則,匹配命中後執行規則(您能夠設置啓動時直接啓用,詳見【3.6.2】『http tamper setting』)
在篡改規則列表區任意位置右鍵可提出Rule控制菜單
  • remove selected rule 刪除選定規則
  • remove all rule 刪除全部規則
  • enable this rule 生效指定規則
  • enable all rule 生效全部規則
  • unable all rule 讓全部規則不生效
  • edit this rule 編輯當前規則
 

5.2 Tamper Rule信息顯示

如上圖您建立的規則都會顯示在Tamper Rule列表裏,每條規則在列表處顯示信息依次有以下4項
1:是否進行匹配複選框(若是您想要篡改規則生效,除了要設置『啓用』控制,還須要將此處設置爲勾選狀態)
2:替換/編輯圖標,該處僅顯示一個圖標表示當前篡改規則是一個編輯規則仍是替換規則
3:當前篡改規則的的序號,注意該序號是自動生成的惟一序號,在您對規則作添加或刪除操做時會從新生成每條規則的序號
4:規則名稱,若是您沒有設置規則別名這裏會直接顯示匹配url的方式加匹配url值(別名的設置請參考【1.3】『adit advanced http filter』)
 
如上圖,但您將鼠標移至rule圖標處會顯示規則匹配的詳細內容(僅顯示匹配信息,不顯示篡改詳情)
上圖規則表示當請求同時知足 如下規則1:請求url 必須等於「 https://www.fiddler2.com/UpdateCheck.aspx?isBeta=False
2:請求必須含有名爲「Data」的請求頭,且該請求頭的值含有「GMT」
3:請求Body必須含有顯示的字符串
 

5.3 Rule的編輯及排序

如上圖您在rule列表對任意篡改規則進行雙擊則進入編輯模式,對當前規則進行編輯
處於編輯模式的rule在列表處以紅色背景展現,在圖中紅線出也顯示了當前編輯面板的狀態
請注意編輯完成後務必點擊保存使更改生效(保存成功後當前rule規則特殊背景色會消失)
若是您想放棄修改請點擊取消(詳見:【3.2】『cancel edit』取消)
規則的匹配是由上至下的,因此最上面的規則會被先匹配到,若是您『is only match fist tamper rule』設置的是On,那若是有2個生效規則均可以被匹配到,實際當前一個匹配規則匹配成功即會中止下面的匹配,這種狀況下規則順序的更改將十分必要
順序調整也十分便捷,您只須要選擇您想要調整位置的rule(支持多選),將它拖動到您須要的位置便可
 

六:快速入門

這裏向您演示如何快速建立一個規則,並完成對http請求或響應的修改
https://www.fiddler2.com/UpdateCheck.aspx?isBeta=False爲例(該請求實際爲fillder更新檢查的請求)
假設咱們但願修改url中isBeta的值爲ture,並將Connection:頭修改成Keep-Alive
您只須要在填入如上圖所示信息,點擊右下角確認
如上圖設置開啓規則匹配並勾選您須要參與匹配的規則(圖中序號爲6的的請求便是咱們剛剛建立的規則)
 
當系統匹配到http請求後,會將fiddler左側session列表中被匹配中session,及右側rule列表被匹配中規則同時以淺黃色高亮提示(rule列表處高亮提示將在2-3秒後消失),同時在Log日誌區會出現相應日誌
篡改結果如上圖Inspectors標紅處,能夠看到對http的修改已經生效
 

七:簡單實踐

目標:將baidu首頁的logo替換爲google的logo
咱們先找到baidu首頁logo的請求爲: https://www.baidu.com/img/bd_logo1.png
咱們在網上搜索獲得一個google的logo: https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Google_2015_logo.svg/220px-Google_2015_logo.svg.png (若是您沒法訪問這個連接,您能夠選擇任意一個其餘的圖片url進行測試)
經過FreeHttp咱們有多種方案能夠完成目標
1:使用『Request Modific』修改請求url內容讓他實際請求google的logo
如上圖設置規則便可
效果如圖實際請求baidu logo的請求實際被修改成了google的(這些改動對客戶端瀏覽器是不可見的,不過由於是圖片文件因此您在測試的時候請注意瀏覽器緩存)
 
2:使用『Response Replace』修改請求重定向到google的連接
如上圖設置規則便可(若是您剛剛設置了對該圖片連接的Request Modific規則,爲了避免影響測試過程請將前面的規則設置爲不可用)
 
效果如圖,bd_logo1.png的請求實際被重定向到了新的地址,一樣實現了剛剛的效果
 
3:使用『Response Replace』直接替換返回圖片內容
如上圖設置規則便可(本地圖片須要提早準備)
效果如圖(效果是同樣的實際原理稍有不一樣,此次是直接使用本地文件更改的請求響應)
 
4:使用『Response Modific』修改百度首頁HTML,將圖片元素的地址修改成google的連接
如上圖設置規則便可(注意此次不是修改 https://www.baidu.com/img/bd_logo1.png的響應了,Url Filter匹配的是 https://www.baidu.com/
效果如圖,能夠看到此次百度首頁的HTML的地址直接被修改了,瀏覽器解析到被篡改的url從而請求了錯誤的圖片
 
 
 

八:參數化數據設置

參數化數據的使用可讓您使用篡改規則動態的修改http的內容,而且支持在http請求或相應中捕獲數據供篡改規則使用
當前版本支持如下類型的參數化數據 (全部種類的參數化數據可使用『=』當前值,『+』下一個值,『-』上一個值這3種方式進行取值)
Key-Value 這是最直接的參數類型,僅提供Key Value 功能,通常用於固定常量,或存放從HTTP報文中捕獲的數據
Index 該參數類型提供一種相似索引的功能(您能夠設置它的起始值及範圍,還能夠設置每次取值的進步) (the max is 2147483647)
LongIndex 該參數類型與Index相似,不過LongIndex提供了更大的範圍(the max is 9223372036854775807)
StringIndex 該參數與與LongIndex相似,不過它提供一直固定長度的索引(如0001到9999而不是1到9999)
Time 該參數可讓您以指定格式獲取當前時間
Random 該參數可讓您以指定格式獲取一個隨機字符串/數
List 該參數提供一組特定列表,如「小紅」,「小黑」,「小花」,您可使用該參數依次或隨機取出設置的3個值
CSV 該參數可讓您直接使用CSV文件中的數據
 

8.1 『parameter data manage』參數化數據管理器

點擊Modific Tool中的parameter data manage 便可彈出如上圖所示參數化數據管理器(在request replace 機response replace 編輯區右鍵菜單中add parameter data -> edit data 也能夠打開該管理器)
參數化數據管理器只要用於集中管理您所添加的參數化數據
 

8.1.1參數化數據管理器基本顯示及操做

如上圖『parameter data manage』主要分如上3個部分
1:parameter data manage類別 (點擊不一樣的類別分類能夠進行列表切換)
  • KeyValue:包含Key-Value參數列表
  • Parameter:包含Index,LongIndex,StringIndex,Time,Random,List參數列表
  • DataSouce:包含CSV參數列表
 
2:參數列表
列表依次顯示參數的名稱,類別,當前值(可能每一次取值都不同,列表僅顯示當前值)
您能夠經過列表右上方添加刪除按鈕添加刪除參數
3:控制當前參數
您在參數列表中選擇任意參數,該參數會在這裏進入編輯模式
該區依次顯示參數名稱(不可編輯),當前值(可編輯),控制按鈕
控制選項一共有3個
  • 編輯當前值:點擊該按鈕即爲用該區文本框中的內容設置當前參數(注意並非任意值都是合法的,如字母「ABC」就對一個Index類型的參數必定不合法)
  • 取下一個值:獲取當前參數的下一個值
  • 重置參數:對當前參數進行重置
 

8.1.2添加參數化數據

如同點擊添加按鈕彈出添加框,依次選擇填寫圖中4處信息便可完成添加
1:下拉選擇參數化數據類別(大類別)
2:下拉選擇參數化數據具體類別
3:填寫您須要添加的參數化數據名稱
4:填寫您參數化數據的格式要求(當您選擇完類別後回顯示格式要求,含義及示例在圖中黃色高亮區域,以幫助您填寫正確的格式要求)
填寫完成後點擊添加便可完成添加
 
如上圖設置將會添加一個名爲RandomId,類型爲Random的參數化數據,該Random參數爲10位長度的數字
如上圖設置將會添加一個名爲csv,類型爲CSV的參數化數據,該Random使用本地文件D:\data.csv做爲數據源並以UTF-8讀取數據
注意若是添加CSV類型數據後,若再在計算機中單獨在對改文件直接進行編輯後,您須要從新添加該數據源才能使您的編輯生效
 
 

8.1.3查看編輯導出CSV類型數據

您在任意一個CSV數據類型上雙擊都會彈出數據源顯示/編輯框
如上圖您能夠選則csv表格中的任意數據(由於實際CSV參數取值都是按從左至右從上至下順序取值,因此但其遊標十分重要,您選擇的數據再您保存後將成爲該參數的當前數據)
您一樣能夠編輯(雙擊任意項能夠進行編輯),刪除(選擇行按鍵盤Delete),添加(在尾行直接統計)
完成編輯後您能夠點擊左上角save data圖標進行保存,或點擊export data將您的數據直接導出爲文件(CSV參數裏的數據可能所有來自HTTP捕獲,因此導出可能對您十分必要)
 

8.2 在規則中使用參數化數據

您在參數化數據管理器中添加的參數能夠在『Request Replsce』,『Response Replace』規則中直接使用

 

8.2.1 使用插入的方式添加參數

如上圖您能夠在『Request Replsce』或『Response Replace』編輯區域鼠標右鍵,在右鍵菜單中選擇add Parameter Data ,選擇添加參數的類別,選擇您要添加的參數(這裏選擇的是剛剛添加的ran2),最後選擇取值方式
完成選擇後參數會自動添加到光標後方(圖中黃色高亮區域)
 

8.2.2使用拖拽的方式添加參數

如上圖所示您能夠在參數管理器中選擇您須要的參數直接拖拽到編輯區的任意地方,一樣會爲您自動完成添加(以拖拽添加的參數的取值方式都是「下一個」,您能夠手動修改)
 

8.2.3使用手動編輯的方式進行添加

只要按照指定格式*#參數名稱(取值方式)*#您能夠本身手動添加參數
參數名稱須要是已經存在的參數名稱
取值方式默認有 下一個(+),上一個(-),當前值(=) 3種可使用
CSV數據參數除支持上面3種默認取值方式外還支持使用二維座標系地址取值,好比 *#dtb(0-2)*# 表示取dtb這個csv數據源的第0列,第2行數據(以0爲起始索引)
默認下一個取值(+)還支持(+N)後面第N個的取值方式
 
注意使用手動添加參數後須要手動勾選use Parameter Data
 

8.3 動態拾取參數化數據

FreeHttp動態獲取http報文中的數據用於設置或添加參數
如上圖在控制條中有『set parameter pick info』圖標(【3.4】節)
您能夠在Http請求報文,或響應報文中拾取參數,這取決於您當前建立的篡改規則的類型
點擊圖標便可進入參數拾取規則設置窗口
如上圖按提示依次填入參數名稱,拾取方式,拾取附加項,拾取範圍,拾取表達式,而後點擊添加或刪除按鈕
 
  • 參數名稱:若是使用的參數名稱已經存在於參數管理器中,該拾取會修改當前參數的參數值(修改實際都是修改下一個值,對Key-Value來講當前值與下一個值都是同一個值),若是是一個新的參數則會直接添加一個Key-Value型參數
  • 拾取方式:當前版本支持Regex,XML,String 3種拾取方式
  • 拾取附加項:對拾取方式的附加說明
  • 拾取範圍:不管是請求報文仍是響應報文,都支持以Line請求/響應行,Heads 請求/響應頭,Entity 請求/響應實體爲查找範圍
 
下面以Regex爲例(Xml使用Xpath與Regex是相似的),說明參數拾取規則的填寫(獲取User-Agent括號內的數據)
Parameter Name填寫ua_1,PickType選擇Regex
PickAdditional選1,1表示取匹配結果的第一項(由於Regex於Xpath匹配均可能是多個結果),0表示把多個結果以逗號鏈接在一塊兒返回,固然您能夠手動填寫2,3,4等索引表示取第N個價格
PickRange 選擇Heads (由於User-Agent在head頭中)
Pick Expression 填寫 \(.*?\)
 
若是您對Regex還不是很熟悉能夠直接使用Str(使用Str一樣能夠完成大多數的查找)
如上圖,選擇PickType爲Str,PickAdditional爲str-str(str-str:字符串首尾拾取目標值,str-len:使用指定字符串開始並指定長度,index-len:以指定索引開始並指定長度,長度填0則表示拾取到最大長度)
PickRange依然選擇Heads,Pick Expression 填寫 (-)
 
最後如上圖使用str-len獲取請求行中的isBeta參數,完成後點擊確認
 
在HTTP請求被匹配命中後,即會執行設置好的參數拾取,如上圖參數已經在請求報文中拾取出來了(注意用Str方式匹配的結果是不含有首尾字符串的,因此上圖ua_2會少一個括號)
參數拾取過程也會被打印在日誌區
 

8.4 參數化數據示例

目標:匹配www.test.com/parameter?name=value請求,並返回{"mes":"hello value"}
其中www.test.com是一個不存在的域名,value多是任意字符串 (實際是對不存在接口的mock)
 
以下配置便可
如上圖添加一個Request Modific規則,由於實際只須要獲取name名稱不須要對請求進行修改,因此修改區域不用填寫而後信息(不修改),僅添加一個參數拾取規則便可
如上圖再添加一個Response Replace,由於實際接口是不存在的全部必須手動替換一個虛擬的返回,返回body中使用到了請求將會獲取的testName參數(注意勾選Response Direct)
 
完成添加後,設置剛剛添加的2個規則生效。
 
 
如上圖,您在使用瀏覽器(對使用fiddler代理的任何設備任何客戶端都生效)訪問 http://www.test.com/parameter?name=tom
能夠看到這個並不存在的接口已經按預期返回了數據,而且成功取出了name
 
 
 
 

實現及源碼

 
Fiddler 擴展插件開發環境配置 請參考官方文檔 https://docs.telerik.com/fiddler/Extend-Fiddler/ExtendWithDotNet (該文檔已經詳細說明了搭建及調試項目的過程)
Fiddler 對外開放接口能夠參見《Lulu.Debugging with Fiddler》(書中不只介紹Fiddler的起源,還纖細介紹了Fiddler的使用,其中就包括對外提供的擴展接口)
 
當前FreeHttp控制使用.net framework 版本爲4.5(您在配置開發環境時須要注意您調試引用的Fiddler 的版本,及您開發環境所支持的最高版本)
 
基本基本結構以下圖
 
下載工程並加載成功後您能夠看到如上圖的基本結構
  • 1:AutoTest命名空間主要提供參數化數據的拾取及管理
  • 2:FiddlerHelper命名空間 提供與Fiddler篡改直接相關的功能
  • 3:FreeHttpControl命名空間提供UI界面及窗體操做邏輯
  • 4:HttpHelper命名空間提供對HTTP協議報文處理的功能
  • 5:MyHelper 命名空間提供公共的輔助工具
  • 6:WebService命名空間提供使網絡服務的功能
  • 7:FiddlerFreeHttp繼承至IAutoTamper,他是與FIddler數據交換的入口  , FiddlerSessionTamper是FiddlerFreeHttp的工具類
 
您能夠根據本身的須要直接修改FreeHttp各部分的代碼以改動或擴展FreeHttp的功能,使他更符合您的需求。
若是您發現了任何問題或是意見請請在 https://github.com/lulianqi/FreeHttp/issues 直接提出您的文件 (您也可能經過郵箱聯繫 mycllq@hotmail.com提出您的問題或建議)
相關文章
相關標籤/搜索