抓包工具Fiddler篡改請求響應報文

簡介

客戶端和服務器通信發送報文進行通訊，但這些報文可以被截獲修改進行一些攻擊。對於web端和app都可以查看源碼判斷解密算法，並且大部分情況下都可以僞造響應報文，尤其是未加密和簽名的報文。對於RSA加密報文可以利用之前獲取成功報文，直接返回給特殊功能進行繞過攻擊。例如截獲新增用戶成功響應的報文【可以是加密後的報文】，在驗證短信界面直接截獲返回成功響應的報文給驗證短信界面。如果客戶端未採取包順序標記驗證等措施，就會判斷成功直接跳到下一級界面。

嘗試抓包截獲

• 安裝fiddler工具，百度下載。

• 打開工具並設置如下
  

• 隨便找一個網頁開始發送報文到後臺，正常返回界面如下
  

• 點擊網頁提交表單，會發現fiddler截獲了報文，雙擊左邊的記錄如下圖。
  

• 點擊截獲響應報文 上圖箭頭所示 break on response，並且修改響應報文如下圖。
  

• 網頁獲得的報文是被篡改的報文
  

拓展解讀

HTTP傳輸

通過抓包軟件可以發現請求頭和響應頭最終會按ASCII編碼轉換爲16進制，最終轉換爲2進制在網絡上傳輸。請求body會根據content-type編寫的字符集編碼進行轉換，例如UTF-8。而GET請求tomcat默認是ISO-8859-1傳輸，所以中文需要encodeURL編碼再進行傳輸，服務端Decoder解碼。

APP短信繞過攻擊

例如一個app有普通字典功能，可以通過抓包工具抓取成功返回的報文加入爲 {succ:true}亦或是加密後的 {OFBSSDFFDDDF}。這個時候短信認證界面隨意輸入驗證碼，通過抓包工具截獲，將剛剛截獲成功的報文返回給app即可讓應用認爲驗證通過。這個是利用軟件所有成功返回的報文一致來進行模擬攻擊。解決這個問題就必須要求響應報文具備兩個條件：

1、成功報文要是動態
2、舊的成功報文不可通過校驗

當然也可以後端自己做業務的時候判斷用戶是否真的短信驗證通過，但是如果前端不能避免抓包攻擊的話，很多查詢接口都會暴露出來。

解決思路：

1、成功報文加時間戳，並且前端需要傳遞序列號到後端，後端原封不動返回。
2、前端解密後驗證序列號是否與請求一致。防止歷史成功報文驗證通過。
3、因爲前端代碼和app代碼都會被人破譯查看，所以加密算法應該爲非對稱加密，這樣抓包者無法模擬成功報文，只能利用歷史成功報文攻擊，但因爲有序列號所以無法驗證通過。

以上只是初步一個想法，並未實踐，做一個簡要記錄。