通过之前的抓包WireShark抓包报文结构分析,我们大概可以看出,WireShark的报文结构类似于TCP/IP四层模型。报文封装的最内层为封装的业务数据,最外层对应报文转发所需参数。
实际对应起来就是报文最外层的Ethernet II封装对应数据链路层,为TCP/IP四层模型的最底层,主要是以ARP和RARP协议为基础,实现报文数据在物理媒介上的传输;
报文第二层的Internet Protocol封装对应网络层,为TCP/IP四层模型的第二层,主要依靠IP协议(最明显的特点就是IP地址)来完成报文的网络到网络转发;
报文第三层的Transmission Control Protocol对应传输层,为TCP/IP四层模型的第三层,主要依靠TCP协议或UDP协议完成报文的端到端传输。可能有同学觉得IP到IP不就是端到端的转发了吗?其实不全是,以之前的抓包数据为例,报文是封装有源目端口号的;在实际网络中,大量使用了NAT地址转换,只将一些关键服务器的端口映射到了公网上,必须经过地址转换才能到达实际的服务器,所以一般只有通过指定的IP+端口号才能确定到指定主机(负载均衡等场景除外),所以说是IP+端口号的TCP或者UDP协议完成了报文的端到端转发;
报文第四层,一般也是最内层的Data或者其他知名协议(如HTTP、DNS、Telnet等)对应应用层,为TCP/IP四层模型的第四层,也是最上层,主要负责封装或者传递业务数据。应用层协议复杂多样,通过抓包也能看到大量的不同协议报文,如HTTP、NBNS、DHCP、DNS等等。
其实这个封装和转发过程和邮寄快递也有相似之处,比如北京A公司的AA寄一份合同给杭州B公司的BB,合同装进文件袋就是打了一层封装,AA和BB即对应TCP协议的端口号,A和B公司及对应网络层的IP地址,快递公司的转发即是数据链路层的转发。文件到达B公司并不算是完成端到端的转发,必须指定BB来收件,才算是完成了端到端的转发;而当BB签收文件袋的时刻,才完成了这一次可靠的邮件寄送;放到网络中,就是一次报文转发。而当寄送的文件过多时,就会被打包成多个包裹,在网络传输中,就是报文的分片。
之前也提过,Telnet报文交互时,数据是明文交互的,就好比AA和BB交互的合同信息被放在了一个透明的文件袋里,传输过程中的任何一个人,只要想看,就能看到报文内容;而使用SSH交互时,叫好像双方都有一对钥匙,配合使用才能打开文件袋,传输过程中报文可能被截获,但是很难被破解。
本次我就做个测试,抛开传输层以下交互,看看HTTP协议下,AA和BB交流了哪些信息,以及是怎么交互的。
HTTP报文交互一般产生在浏览器浏览网页时,常用的查看工具有HttpWatch和F12(开发人员工具)。从电脑上访问一个WEB页面(一台设备的管理页面),同时开启HttpWatch和WireShark记录,获取结果如下:
WireShark:
HttpWatch:
简单来看,可以看出报文交互过程是一致的,HttpWatch中的1个POST和9个GET动作在Wireshark中均有体现,不过顺序有细微差异。
因为使用的是基本版的HttpWatch,能看的信息很少,除了上图中的摘要信息,查看其他所有详细内容都要专业版的授权。(所以HttpWatch算是测试途中被放弃了,有人有专业版的授权或者破解版本可以共享我一下的吗?)
然后我就试了一下IE浏览器的F12(开发人员工具),能得到的内容竟然比HttpWatch基本版要详细。
然后看一下交互报文的详细信息。
网络层的封装中,可以看到请求源地址和目的地址。
传输层的TCP封装中,可以看到目的端口为80端口,为标准的HTTP协议端口。
在第一个POST报文中,可以看到客户端是在请求设备的login页面,URI为http://172.2.215.175/web/device/login?lang=1。
拆分开看,请求方式为POST,主要是用于向指定的资源提交要被处理的数据;另一种请求方式为GET,用于从指定的资源请求数据。在请求的同时,客户端还发送了自身的相关参数,如要求使用语言为中文,客户端的操作系统为Windows NT 6.1(Windows 7),64位版本,;浏览器内核为Trident/7.0,版本为11.0,也就是IE 11。至于显示的User-agent为什么是Mozilla,建议大家百度一下,有一个小故事。
https://zhidao.baidu.com/question/1767408752449075980.html
通过客户端发送自身的信息,服务侧就知道响应何种报文了。这种做法现在很有用并且也很常用,因为目前终端类型特别多,如果服务商只提供一种类型的页面很难保证都适用;所以服务商针对主流厂商和操作系统做了定制,而只需要识别到终端类型即可返回对应类型的交互页面了。(PS.现在很多浏览器也支持修改浏览器标识,比如电脑端修改为手机端,手机端修改为电脑端,安卓也可以使用Safari标识等)
报文最后还有一段上传的uid(用户ID)值,同时说明了HTML表格编码格式,此处所用的application/x-www-form-urlencoded格式为浏览器默认的编码格式。
同时对于封装的二进制报文,可以发现右侧能直接翻译出报文内容,采用的是ASCII ((American Standard Code for Information Interchange): 美国信息交换标准代码)编码格式。网上有标准的字典,同时一些工具,如EditPlus左侧现有对应的字典显示。
而在F12工具中,虽然看不到报文的封装,但是HTTP协议封装的内容看起来更加简洁明了。
在WireShark中,每个报文都是分开展示的。
而在F12工具中,则会将一组请求报文和响应报文组合在一起,按照请求标头、请求正文、响应标头、响应正文的顺序进行显示。如上图所示,可以看到正文中是一个HTML页面的代码,对于熟悉HTML编程的人员来讲,可以很清晰的了解页面格式和内容;如果有攻击行为,则可以截取报文,修改报文以达到篡改页面、欺骗最终用户的目的。
前面提到HTML页面报文,中间有部分嵌套的CSS格式、javascript、图片等资源,客户端在收到响应之后继续请求这些资源。
可以看到,客户端后续共请求了8个资源,也是路径+文件的形式进行请求的。通过这些,我们也可以探测服务侧的存储路径,如果权限或者方法合适,我们甚至可以将整个路径获取下来,或者拿到自己想要的文件信息。
而对于登录页面的验证码信息,通过多次尝试发现,每个验证码都有一个数值与之对应,我在猜测,如果找到对应的算法,是不是能破解出图片的字符。我想网上一些代理登录工具,能跳过验证码验证的就是这么做的,所以现在出了更高级的点击图片、拖动图片等高级验证码。
当然,操作有限,HTTP中的标准动作除了POST、GET之外,还有HEAD、PUT、DELETE、TRACE、CONNECT等等。如果后面会用到的话,再具体问题具体分析吧。