声明
因传播、利用本文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，WondersCERT及文章作者不为此承担任何责任。
WondersCERT拥有对本文的修改权和解释权。如需转载或传播本文，必须保证本文的完整性，包括版权声明等全部内容。未经WondersCERT允许，不得任意修改本文内容，且不得以任何方式将其用于商业目的。
前言
利用抓包工具抓取HTTP应用层的数据包是日常渗透测试的重要环节。HTTP的流量包不仅可以为渗透测试提供重要信息，还可以作为渗透攻击的入口。但在日常工作中，我们经常会遇到无法抓取流量包的情况，这时我们无法知晓服务器与客户端之间的交互情况，测试工作就如同被蒙住了眼睛，无法进行下去。
针对这种情况，结合自身实践总结了几种工作中遇到的无法抓包的情况以及解决方案，希望能给大家提供一些帮助。
代理抓包的原理
首先我们需要清楚，客户端与服务器之间的通讯遵循一种协议叫HTTP。而要抓取HTTP协议中的流量包，就需要借助一些抓包工具，比如常见的Burpsuite、Fiddler等。
Burpsuite、Fiddler和Charles等抓包软件与Wireshark有本质区别，Wireshark侧重数据帧，支持查看多种低层报文及繁多的网络层数据包协议。而Burpsuite等只能抓取应用层协议的数据包，及HTTP、HTTPS、Websocket。
以HTTP为例，浅显易懂的讲解下，客户端与服务端数据传输的过程。
上图是一次完整的HTTP请求，首先客户端通过HTTP请求中的URL（Uniform Resource Locator）寻找IP对应的端口开启的Web Server服务，然后通过HTTP协议预定规则，实现服务器与客户端的数据交互。
而HTTP的代理抓包的原理，其实就是在真实服务器与客户端之间启动一个代理服务器。当我们开启一个抓包工具（如Burpsuite），其实就是开启了一个代理服务器，这类工具都会要求用户设置一个IP及端口。同时相应的客户端主机系统也会被要求配置响应的代理IP及端口，且必须与抓包工具配置的代理信息保持一致。
这样客户端在发起HTTP请求会直接请求系统代理所在的地址，通过代理服务器与客户端进行连接，最终实现代理服务器与真实服务器的连接。
这个过程听起来很复杂，我们可以通过一张图简述流程。
从示意图中可以看出，代理抓包的本质就是在客户端和目标服务器之间多了个“中间人”。服务器和客户端之间的所有数据传输都会被代理服务器获取，期间的数据可以进行篡改，用于渗透测试。
部分应用不能抓包的原因及解决方案
基于以上代理抓包的原理，我们可以知道抓包的本质是要客户端根据系统设置的代理ip加端口去寻找代理服务器，如果发现代理配置信息，才会使用URL去连接代理服务器。
第一种情况-配置不一致
这类无法抓包的情况是很多人容易忽视的低级错误。就是代理软件配置的ip和端口与客户端系统配置的不一致。
比如以burpsuite为例，工具配置的代理信息如下图所示。
而客户端所在的系统配置却与代理软件不一致。
这时候客户端去寻找代理服务器，就会无法找到指定目标，导致抓取流量包的信息失效。这个问题虽然是一个低级错误，但却是一些新手甚至部分有经验的测试人员容易忽视的问题。
所以当我们遇到代理软件无法抓包的情况，首先第一反应就是排查客户端系统配置的代理信息是否与抓包软件配置的一致，如果不一致将其修改一致，然后再次尝试抓包。
第二种情况-多代理优先级
这也是一种比较容易忽视的问题。当客户端开启了全局代理后，其他的代理信息会被覆盖，所有的信息都会优先通过全局代理。这时候抓包软件或者客户端配置的代理信息就会失效，应用的流量包自然无法按预期被抓取。
IE的局域网设置即为全局代理。
此时抓包工具、移动端配置的代理信息将会与其发生冲突，从而无法如预期抓取流量包。
解决这种问题的方法就是关闭全局代理，然后再配置抓包工具与客户端的代理信息保持一致。
第三种情况-请求校验超时
在日常渗透测试中，我们会发现直接使用burpsuite对小程序或者APP进行抓包，请求的响应速度会变得特别慢，而且经常会抓不到包，而替换成Fiddler后却能快速且成功抓取流量包。
这主要是因为Burpsuite是基于Java开发的工具，面向专业的安全工程师们，内置集成了许多优秀的功能工具。解析速度相对于专注跟踪HTTP/HTTPS 流量，只适配Window的Fiddler会慢很多。恰巧有的APP、小程序会对请求、响应时间做限制，这时候burpsuite丢包的情况就会出现。这也是Fiddler能抓到的包Burpsuite却抓不到的原因。
基于上述原因Fiddler虽然可以抓包，但相比于Burpsuite却少了很多渗透测试的功能，这对于安全工程师来说是极其不便的，这时候我们可以采取BurpSuite和Fiddler相结合的方式来解决这个问题。
具体操作步骤如下：
首先配置burpsuite的代理信息。
然后在Fiddler中配置burpsuite的代理信息，两者必须保持一致。
最后在Fiddler中配置真正的代理端口信息，该端口必须与需要抓包的客户端代理信息保持一致。（如果是浏览器，那需要在浏览器中配置相应的IP及端口信息；如果是移动端，需要在WIFI中配置相应的端口信息）
注意：此方法必须先开启Burpsuite，后开启Fiddler，否则将无法成功抓包。
解析：本质是通过Fiddler配置真正的代理信息，快速全面的抓取流量包，然后将Burpsuite挂载在Fiddler中，实现流量转发。这样既能成功抓取流量包，又能使用Burpsuite进行安全测试。
第四种情况-针对移动端
在手机端测试某些小程序或者APP时，对以上方法都进行了尝试，还是无法抓取流量包。这种情况可能就是我们下面提到的第四种情况。
正常情况下系统代理设置后，HTTP客户端会首先去寻找系统代理信息，然后用完整URL去请求服务器资源。
HTTP客户端也允许开发平台不使用默认的系统代理信息，开发者可以根据自身的需求单独设置需要使用的代理信息。这时候客户端就不会使用我们设置的代理信息，那我们的抓包工具自然就无法获取任何流量信息。
针对这种情况我们可以使用VPN将服务器流量转发到代理服务器。
具体操作如下：
首先在手机安装VPN软件，此处推荐Drony。
（）
Droy会在安装的手机上创建一个VPN，将此设备上所有的流量都转向自身，然后再将流量通过代理信息转发给指定抓包工具，这样我们就能实现抓包了。
如图，Drony安装成功后默认是OFF(关闭)状态，我们需手动开启ON状态。
接着配置Drony转发，滑动到SERRINGS，并点击Wi-Fi配置
选择我们当前连接的网络，且网络必须与抓包工具（Burpsuite）等所安全的设备网络保持一致。
代理选择Manual，Hostname和端口（此处与Burpsuite等抓包软件配置的代理信息保持一致）。Proxy type 选择Plain http proxy
Filter default value选择Direct all
接着选择Rule,点击+，增加需要使用代理的APP（也就是我们需要测试的APP）
然后按照截图配置APP的规则。
最后一点，我们需要在PC端检查抓包软件的代理配置是否与Drony保持一致。
如果上述步骤都成功完成，就会发现流量可以成功被抓取了。
总结
回顾一下上述的抓包解决方案，需要对HTTP请求从发送、寻址、服务端响应等整个流程有透彻的了解。当其中的某个环节出现异常，可以通过排查法依次进行排查，最终找到一条有效的解决方法。
使用HTTP协议在互联网上进行数据传输是一种不安全的方式，可以根据实际业务场景使用HTTPS或非HTTPS的解决方案（如WSS等）进行升级改造，APP端则可以使用HTTPS双向校验来加强数据交互。
END
WondersCERT