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

2021-08-18 08:48王春苗刘玥
电脑知识与技术 2021年18期

王春苗 刘玥

摘要:本文基于实际发生的案例,介绍了在全国会计中级无纸化考试考前调试过程中,出现的考生端程序访问服务端程序持续处于严重“卡顿”状态的问题。文章针对出现的网络访问和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.

【通联编辑:王力】