基于BurpSuite的Web應用故障分析和研究

王春苗 劉玥

摘要：本文基于實際發生的案例，介紹了在全國會計中級無紙化考試考前調試過程中，出現的考生端程序訪問服務端程序持續處于嚴重“卡頓”狀態的問題。文章針對出現的網絡訪問和Web應用故障進行逐步分析和思考，并結合Wireshark、BurpSuite和tcpdump等工具軟件進行綜合調試，通過BurpSuite記錄了Web瀏覽器運行“加載項”列表內容是后臺進程的全部數據訪問請求，并在此基礎上繼續通過tcpdump程序驗證TCP協議SYN連接超時和重發時間間隔機制，從而找出故障發生的原因和原理，并最終解決問題。

關鍵詞：Wireshark;BurpSuite;代理偵聽;加載項;tcpdump;SYN超時

中圖分類號：G642? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2021）18-0017-03

開放科學（資源服務）標識碼（OSID）：

B/S架構的Web應用程序開發過程中，常常調用Web瀏覽器來完成向服務端的訪問請求。此時，如果Web瀏覽器本身由于種種原因出現問題，那么對Web應用程序的排障將是一個很大的挑戰。Burpsuite是Web滲透測試領域的“利器”，利用它可以實現對Web瀏覽器的所有數據訪問過程的監控甚至修改，而tcpdump則是一個全方位的數據包捕獲和分析程序。結合BurpSuite和tcpdump，可以輕松實現對Web應用程序進行故障分析研究，并得出最佳的解決方案。

1 問題場景和故障現象描述

會計中級機考采用B/S網絡架構，考試服務端和所有考場機房都位于互聯互通的三層交換網絡，考試客戶端軟件后臺通過調用IE瀏覽器的方式來訪問考試服務器的Web服務，并實現對桌面的鎖屏以防止切換，考試主管部門要求正式考試時必須斷開考場機房的互聯網連接。

在考前調試過程中，當配置出口防火墻策略關閉考場機房到互聯網的連接通道后，發現所有考場運行考試客戶端軟件時，均出現卡頓和白屏現象，等待大約15秒，方才出現考生登錄輸入框界面，登錄成功后，在模擬考試的過程中，也頻繁出現卡頓現象;當重新配置出口防火墻策略允許考場機房到互聯網的連接后，再次重新打開考試客戶端軟件，此時登錄輸入框界面快速顯示無延遲現象，登錄成功后，再次模擬考試，此時操作流暢且無卡頓現象。

2 故障分析研究

當斷開考場的互聯網連接時，考試客戶端訪問服務端出現嚴重卡頓，而允許考場機房訪問互聯網時，考試客戶端訪問服務端一切正常。那么首先排除內網服務器故障的可能性，猜測客戶機系統存在某個進程持續嘗試訪問互聯網，網絡斷開時，該進程頻繁訪問失敗，導致考試客戶端產生嚴重卡頓現象。那么如何才能找出這個進程，這是問題的焦點所在。

2.1 首先檢測客戶機系統是否感染了病毒

檢查內容包括進程占用CPU情況、進程占用內存大小情況、本地硬盤是否頻繁讀寫以及使用新版殺毒軟件掃描考試客戶端軟件和全盤掃描查殺等。通過實測，基本可以排除客戶機系統感染病毒的可能性。

2.2 猜測考試客戶端軟件是否存在訪問官方服務器的行為

考試服務端和考試客戶端都位于三層交換內部網絡，從這個角度分析，考試客戶端沒有必要訪問考試承辦公司位于公網的服務器。通過木馬專殺類工具程序實際檢測考試客戶端，沒有發現此類“后門”;另外，通過和考試承辦公司技術工程師反復溝通后，確認考試客戶端不存在訪問官方服務器的代碼;同時，經過咨詢其他考點學校，得知并沒有發生此類故障現象;

2.3 TCP數據包捕獲和分析

排除了上述2.1和2.2的可能性后，依然可以猜測該進程存在訪問互聯網的行為，那么嘗試通過抓包獲得線索。在客戶機上啟動Wireshark抓包軟件并設置偵聽網卡和開啟抓包，然后打開考試客戶端軟件，等待登錄窗口界面出現后停止抓包。由于捕獲的數據包較多，需要應用篩選過濾才能得到有用的數據包，篩選過濾表達式如下：

！（ip.addr == 192.168.104.249 or ip.addr == 192.168.10.1 or ip.addr == 192.168.7.84 or ip.addr == 192.168.72.255 or ip.addr == 224.0.0.252 or ipv6 or arp or lldp）

過濾表達式去除了當前內網環境的3個內網服務器IP地址、一個廣播地址、一個組播地址、IPv6協議和LLDP協議，然后進行排序，顯示結果如圖1所示：

抓包結果顯示，對于同一個目標地址存在較多的TCP-SYN連接請求，即“TCP三次握手”的第一步，顯然在斷網的狀態下，TCP三次握手是無法完成的，上層會話也不可能建立成功，因此可以排除TCP-SYN攻擊的可能性。但是截圖中依然存在不確定的疑點，即連續三個TCP-SYN數據包之間的時間間隔分別為3秒和6秒，記錄下該線索，作為后續分析的參考數據。

2.4 http數據包捕獲和分析

基于tcp協議的上層應用很多，所以上述發現的TCP-SYN連接疑點并不能準確判斷故障源，故障范圍可以進一步縮小至考試客戶端軟件本身。通過咨詢技術客服得知考試客戶端軟件的實質構成包括“指向內網考試服務器的IP地址”“目標HTTP端口號”“調用客戶機IE瀏覽器的代碼”以及“鎖屏防止切換的代碼”等組件，那么判斷IE瀏覽器可能會產生故障。

現場實測打開IE瀏覽器，發現長時間處于卡頓的狀態，甚至無響應，而IE瀏覽器首頁已經設置為空白頁，正常情況下，不會產生任何到互聯網的訪問請求，那么IE瀏覽器在啟動過程中究竟產生了什么行為呢？接下來通過BurpSuite捕獲http數據包并加以分析。

1） 在考試客戶機上啟動BurpSuite軟件，首先是配置代理偵聽：選項標簽Proxy ->子選項標簽Options ->選中默認的代理偵聽，點擊Edit->Specific address：127.0.0.1 -> OK，配置結果如圖2所示：

2） 配置IE瀏覽器的代理指向BurpSuite的代理偵聽地址和端口

首先設置起始頁為空白頁，并刪除所有的緩存文件。然后設置IE代理：工具 -> Internet 選項->連接->局域網設置->勾選啟用代理服務器，并設置地址為127.0.0.1，設置端口為8080，即保持和Burp Suite設置的代理偵聽一致。

3） 配置出口防火墻策略，斷開考場機房到互聯網的連接，并暫時關閉Burp Suite的攔截功能（設置為“Intercept is off”），然后打開IE瀏覽器，發現即使設置了空白首頁，瀏覽器標簽頁依然顯示“正在連接...”，等待15秒左右后，標簽頁顯示“空白頁”，狀態欄顯示“完成”，說明瀏覽器進程后臺已經完成了一系列操作。此時，轉到Burp Suite，點擊“HTTP History”子標簽，可以查看到IE瀏覽器所發送的一系列http請求數據包，顯示結果如圖3所示：

根據上圖分析可知，IE瀏覽器在啟動后，后臺進程不斷嘗試從windowsupdate.com站點下載authrootstl.cab文件，即發送HTTP請求報文。而HTTP請求報文的發送前提是需要首先使用TCP協議成功建立TCP三次握手，TCP三次握手的第一個請求報文為TCP-SYN，由于設置禁止訪問互聯網，導致TCP-SYN連接超時，最終下載失敗，顯然這是導致“卡頓”故障的源頭。進一步測試驗證和分析如下：

使用Centos系統，運行telnet命令向一臺斷開網絡連接的內網PC機請求建立會話，然后通過運行tcpdump輸出TCP-SYN的狀態信息，發現第一個TCP-SYN請求超時后，第二個、第三個、第四個和第五個TCP-SYN數據包的超時等待時間分別為1秒、2秒、4秒和8秒，合計為15秒（和Windows系統上運行Wireshark抓包結果略有誤差）。上圖顯示IE瀏覽器啟動后一共嘗試發送8次http請求，而每一次http請求之前，都將導致15秒的TCP-SYN超時等待，即IE瀏覽器至少在等待15秒之后，才能訪問內網的考試服務端。調試結果如圖4和圖5所示：

3 問題結論和解決方法

那么IE瀏覽器產生的http下載請求的根源是什么呢？答案就是“瀏覽器加載項”，即IE瀏覽器啟動后，首先會加載“加載項”列表中已啟用的所有內容，如果“加載項”列表中存在互聯網訪問請求指令，并且在斷網的前提下，那么就會產生本文所描述的故障現象。

查看和禁用IE瀏覽器的加載項內容：點擊命令欄的“工具”按鈕 ->管理加載項，顯示結果如圖6所示。

分析截圖中的加載項列表，猜測“AccountProtectBHO Class”加載項可能就是發送http請求的源頭。點擊右下角的“禁用”按鈕禁用該加載項，然后關閉IE瀏覽器，再重新打開，此時頁面顯示不再“卡頓”;再次測試打開考試客戶端軟件，登錄輸入窗口界面立即顯示無延遲;輸入賬號密碼登錄成功后，進行模擬考試，整個過程都非常流暢……至此，問題徹底解決！

參考文獻：

[1] 芮辰.基于WireShark和Packet Tracer軟件的域名查詢實驗綜述報告[J].赤峰學院學報（自然科學版），2019，35（10）：61-65.

[2] 俞詩源，王譽天，劉鑫.Burpsuite工具在漏洞檢測中的應用[J].信息網絡安全，2016（9）：94-97.

[3] 蔣小波，沈藝敏，龐富寧.Burpsuite抓包分析注入與提權技術研究[J].數字技術與應用，2019，37（5）：194，196.

[4] 姜慶民，吳寧，閆申友.網絡分析軟件Tcpdump的研究[J].電腦學習，2007（2）：21-22.

【通聯編輯：王力】