你是否正在收集各类网安网安知识学习,蚁景网安实验室为你总结了1300+网安技能任你学,点击获取免费靶场>>
科普贴:
HTTP 是一个无状态的协议。无状态 是指客户端 (Web 浏览器)和 服务器之间不 需要建立持久的链接。这 意味着当一个客户端向服务器端发出请求,然后Web 服务器返回响应 ”*”(response) ,连接就被关闭了,在服务器端不保留连接的有关信息 .HTTP 遵 循请求 (Request)/ 应答 (Response) 模型。客户端(Web 浏览器) 向Web 服务器发送请求, Web 服务器处理请求并返回适当的应答。所有 HTTP 连 接都被构造成一套请求和应答。在 该过程中 要经过4 个 阶段,包括建立连接、发送请求信息、发送 响应信息和关闭连接,如下图所示:
下面 详细介绍上图中描述的HTTP 工作流程,如下
客户端 通过TCP 三次握手与服务器建立连接。
TCP 建立连接成功后,向 服务器发送HTTP 请求。
服务器 接收客户端的HTTP 请求后,将返回应答,并向客户端发送数据
客户端 通过TCP 四次断开,与服务器断开 TCP 连接。
在今天的实验中,我们将通过模拟局域网的两台机器之间的数据传输,配置好HFS软件,来抓取和分析HTTP数据。
根据实验环境,本实验的步骤如下:
1. 配置HFS 软件,获取 HTTP 的 GET数据和POST 数据
2. 分析HTTP数据包
在 局域网环境中,我们使用一个小工具来实现HTTP 服务器。先在 服务器上配置HFS
本地 解压,进入 文件夹,右键以管理员身份运行。如下
我们 先配置HFS ,这里能 达到我们的实验 要求,获取到GET 和 POST 数据包即可。点击左上角 的端口 ,输入 端口,这里我们用8080 , 如下,点击确定
在 虚拟文件系统区域,右键,选择“从磁盘 添加目录”, 选择一个真实 存在的目录(此处注意务必是真实存在的 ),弹出 的选择目录类型 中选择”真实 目录” ,此处 我们用桌面的解压缩目录, 可以看到目录 是红色的
右键 目录,点击设置”用户名及 密码”, 在弹出的对话框中输入 用户名和密码(demo/demo ), 点击 确定。
在右键 目录,点击”属性”, 选择”上传”sheet页 ,选中 任何人。点击确定,这样我们 就配置好了HFS 工具,可以在 客户端通过浏览器访问了。
下面 我们在测试者 机器上,打开Wireshark 抓包工具, 过滤条件输入ip.addr == 10.1.1.33 ,然后输入服务器 中HFS给出 的网址,等待 服务器响应。成功 之后,可以在测试者机器的 浏览器上看到页面, 如下:
这时候, 我们已经获取 到了HTTP 的 GET 方法。 我们将Wireshark 获取的数据包保存为 HTTP-Get。
点击 页面的登录,在对话框中输入用户名密码(demo/demo ),确定 之后等待 服务器响应。成功 如下
接下来 ,双击页面的文件夹(等待 服务器响应), 同时重新启动Wireshark ,等 待页面刷新成功,
如 上图,会 在左侧 看到按钮 ,点击”上传”按钮 ,选择 文件,这里我们选择桌面上的“http-post.txt”,点击 上传。等待 服务器响应。提示 上传成功,如下
我们保存 抓包文件 ,名字 为HTTP-Post。 任务一,就 到这里。
HTTP 由请求和响应 两部分组成,所以对应的也有两种报文格式。下面分别 介绍HTTP 请求报文格式和 HTTP响应 报文格式。
HTTP 请求报文格式
以上 表格中,第1 行 为“ 请求行” , 第2 、3、4 行为 “请求 头部”, 第5 行 为空行,第6 行 为“请求 正文”。 下面分别 介绍这4 部分:
(1) 请求 行:由3部分组成,分别为:请求方法、URL(见备注1)以及协议版本,之间由空格分隔, 请求方法包括GET、POST等。 协议版本的格式为:HTTP/主版本号.次版本号,常用的有HTTP/1.0和HTTP/1.1。
(2) 请求头部包含很多客户端环境以及请求正文的有用信息。请求头部 由“关键字 :值”对 组成,每行一堆,关键字和值之间使用英文“:”分隔。
(3) 空行,这一行非常重要,必不可少。表示请求头部结束,下面就是请求正文。
(4) 请求正文: 可选部分,比如GET 请求就没有请求正文;POST 比如以提交表单数据方式为请求正文。
HTTP 响应报文格式
以上 表格中,第1 行 为“状态 行” , 第2 、3、4 行为 “响应 头部”, 第5 行 为空行,第6 行 为“响应 正文”。 下面分别 介绍这4 部分:
(1) 状态 行由 由3部分组成,分别为:协议版本,状态码,状态码描述,之间由空格分隔。 状态代码为3位数字,200~299的状态码表示成功,300~399的状态码指资源重定向,400~499的状态码指客户端请求出错,500~599的状态码指服务端出错(HTTP/1.1向协议中引入了信息性状态码,范围为100~199)。这里列举几个常见的:
状态码 | 说明 |
---|---|
200 | 响应成功 |
400 | 客户端请求有语法错误,不能被服务器识别 |
404 | 请求资源不存在 |
500 | 服务器内部错误 |
在HTTP的 请求消息 和应答消息中,都包含头域。头域 分为4 种 ,其中请求 头域和应答头域分别只在请求消息和应答消息中出现,通用头域和实体头域在两种消息中都可以出现,但实体头域只有当 消息中包含了实体数据时 才会出现。下面分别 介绍这4 种 头域中的域名城和功能。
HTTP请求头域
Header | 解释 |
---|---|
Accept | 指定客户端能够接收的内容类型 |
Accept-Charset | 浏览器可以接受的字符编码集。 |
Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 |
Accept-Language | 浏览器可接受的语言 |
Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 |
Authorization | HTTP授权的授权证书 |
Cache-Control | 指定请求和响应遵循的缓存机制 |
Connection | 表示是否需要持久连接。(HTTP 1.1默认进行持久连接) |
Cookie | HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。 |
Content-Length | 请求的内容长度 |
Content-Type | 请求的与实体对应的MIME信息 |
Date | 请求发送的日期和时间 |
Expect | 请求的特定的服务器行为 |
From | 发出请求的用户的Email |
Host | 指定请求的服务器的域名和端口号 |
If-Match | 只有请求内容与实体相匹配才有效 |
If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码 |
If-None-Match | 如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变 |
If-Range | 如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为Etag |
If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 |
Max-Forwards | 限制信息通过代理和网关传送的时间 |
Pragma | 用来包含实现特定的指令 |
Proxy-Authorization | 连接到代理的授权证书 |
Range | 只请求实体的一部分,指定范围 |
Referer | 先前网页的地址,当前请求网页紧随其后,即来路 |
TE | 客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息 |
Upgrade | 向服务器指定某种传输协议以便服务器进行转换(如果支持) |
User-Agent | User-Agent的内容包含发出请求的用户信息 |
Via | 通知中间网关或代理服务器地址,通信协议 |
Warning | 关于消息实体的警告信息 |
Accept | 指定客户端能够接收的内容类型 |
应答 头域只在应答消息中出现,是Web 服务器向浏览器提供的一些状态和要求。如下
HTTP 应答头域
Header | 解释 |
---|---|
Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 |
Age | 从原始服务器到代理缓存形成的估算时间(以秒计,非负) |
Allow | 对某网络资源的有效的请求行为,不允许则返回405 |
Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 |
Content-Encoding | web服务器支持的返回内容压缩编码类型。 |
Content-Language | 响应体的语言 |
Content-Length | 响应体的长度 |
Content-Location | 请求资源可替代的备用的另一地址 |
Content-MD5 | 返回资源的MD5校验值 |
Content-Range | 在整个返回体中本部分的字节位置 |
Content-Type | 返回内容的MIME类型 |
Date | 原始服务器消息发出的时间 |
ETag | 请求变量的实体标签的当前值 |
Expires | 响应过期的日期和时间 |
Last-Modified | 请求资源的最后修改时间 |
Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 |
Pragma | 包括实现特定的指令,它可应用到响应链上的任何接收方 |
Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 |
Retry-After | 如果实体暂时不可取,通知客户端在指定时间之后再次尝试 |
Server | web服务器软件名称 |
Set-Cookie | 设置Http Cookie |
Trailer | 指出头域在分块传输编码的尾部存在 |
Transfer-Encoding | 文件传输编码 |
Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 |
Via | 告知代理客户端响应是通过哪里发送的 |
Warning | 警告实体可能存在的问题 |
WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 |
refresh | 应用于重定向或一个新的资源被创造,在5秒之后重定向(由网景提出,被大部分浏览器支持) |
通用 头域既可以用在 请求消息中,也可以用在应答消息。
HTTP通用头域
Header | 解释 |
---|---|
Cache-Control | Cache-Control指定请求和响应遵循的缓存机制,可以附带很多的规定值。 |
Connection | 表示是否需要持久连接 |
Date | 表示消息发送的时间 |
Pragma | Pragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache,用于定义页面缓存 |
Trailer | 表示以Chunked编码传输的实体数据的尾部存在哪些头域 |
Transfer-Encoding | WEB 服务器表明自己对本响应消息体(不是消息体里面的对象)作了怎样的编码,比如是否分块(chunked),例如:Transfer-Encoding: chunked |
Upgrade | 它可以指定另一种可能完全不同的协议,如HTTP/1.1客户端可以向服务器发送一条HTTP/1.0请求,其中包含值为“HTTP/1.1”的Update头部,这样客户端就可以测试一下服务器是否也使用HTTP/1.1了。 |
Via | 列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器,他们用什么协议(和版本)发送的请求。 |
Warning | 用于警告应用到实体数据上的缓存操作或转换可能缺少语义透明度。 |
只有在请求和应答消息中包含实体数据时, 才需要实体头域。 请求消息中的实体数据是一些由浏览器向web服务器提交的数据,如在浏览器中采用POST方式提交表单时,浏览器就要把表单中的数据封装在请求消息的实体数据部分。应答消息中的实体数据是web服务器发给浏览器的媒体数据,如网页,图片和文档等。实体头域说明了实体数据的一些属性。如下表
HTTP实体头域
Header | 解释 |
---|---|
Allow | 列出由请求URI标识的资源所支持的方法集 |
Content-Encoding | 说明实体数据是如何编码的 |
Content-Language | 说明实体数据所采用的自然语言 |
Content-Length | 说明实体数据的长度 |
Content-Location | 说明实体数据的资源位置 |
Content-MD5 | 给出实体数据的 MD5值,用于保证实体数据的完整性 |
Content-Range | 用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度 |
Content-Type | 用于向接收方指示实体的介质类型,指定 HEAD 方法送到接收方的实体介质类型,或 GET 方法发送的请求介质类型 |
Expires | 指定实体数据的有效期 |
Last-Modified | 指定服务器上保存内容的最后修订时间。 |
我们 以HTTP-Get 数据包为例 ,分析GET 方法的HTTP 请求和响应数据包。
我们 打开数据包,输入过滤条件ip.addr == 10.1.1.33,如下
前三个 是TCP 的三次握手,第四个 数据包则是客户端向服务器 发送的HTTP 请求包,我们来学习分析下,
HTTP 之前的协议,本次我们 不做讲解, 不懂的同学可以看之前的实验,我们来看下HTTP 协议。
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n # 请求行信息
Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n # 专家信息
GET / HTTP/1.1\r\n
Severity level: Chat
Group: Sequence
Request Method: GET # 请求方法为 GET
Request URI: / # 请求的 URI
Request Version: HTTP/1.1 # 请求的版本为HTTP/1.1
Host: 10.1.1.33:8080\r\n # 请求的主机
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r\n # 浏览器类型
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n # 请求的类型
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r\n # 请求语言
Accept-Encoding: gzip, deflate\r\n # 请求的编码格式
Connection: keep-alive\r\n # 使用持久连接
\r\n #空行
Full request URI: http://10.1.1.33:8080/ # 请求的 URI 为10.1.1.33:8080
HTTP request 1/8
Response in frame: 2770 #应答 是第2770 帧
Next request in frame: 2775 # 下一个请求是第2775 帧
以上 就是HTTP 请求包的相关信息,可以看到客户端使用HTTP/1.1版本 向服务器发送了GEY 请求,请求 访问10.1.1.33 的 服务器。 将以上 信息填入到报文 格式中,如下
GET方法的HTTP请求报文格式
GET | 空格 | / | 空格 | HTTP/1.1 | \r | \n |
---|---|---|---|---|---|---|
Accept | : | text/html,application/xhtml+xml,application/xml | \r | \n | ||
… | ||||||
Connection | : | keep-alive | \r | \n | ||
\r | \n | |||||
Full request URI: http://10.1.1.33:8080/ |
根据请求包 的信息,我们已经知道, 响应包是第2770 帧 ,下面我们来看下
在HTTP 之前,我们看到了 下图显示的,TCP重组 片段, 这些片段共有2270 个 字节,由于超过 了TCP 数据包的最大数据分段(MSS ),所以将数据在TCP 层进行了分段。 从下面 的信息,可以看到 分断后的数据包及包大小,如#2767 (247 ), 其中2767 表示 帧号,大小 为247 个 字节。
下面 来看HTTP 的具体 部分
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n # 响应行信息
Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n #专家 信息
HTTP/1.1 200 OK\r\n #HTTP 响应信息,响应码为200
Severity level: Chat
Group: Sequence
Request Version: HTTP/1.1 # 请求吧
Status Code: 200 # 状态码
Response Phrase: OK # 响应短语
Content-Type: text/html\r\n # 响应的内容类型
Content-Length: 2023\r\n #包 的长度
Content length: 2023
Accept-Ranges: bytes\r\n #服务器支持 的请求:字节
Server: HFS 2.3 beta\r\n # 服务器类型
Set-Cookie: HFS_SID=0.248448607278988; path=/; \r\n # 设置 Http Cookie
Cache-Control: no-cache, no-store, must-revalidate, max-age=-1\r\n # 缓存控制
Content-Encoding: gzip\r\n # 实体数据的压缩格式
\r\n # 空行
HTTP response 1/8 #HTTP 响应
Time since request: 0.015248000 seconds # 响应使用的时间
Request in frame: 2763 # 请求的帧号为2763
Next request in frame: 2775 # 下一个请求 的 帧号2775
Next response in frame: 2778 #下一个响应 的帧号是2778
Content-encoded entity body (gzip): 2023 bytes -> 4375 bytes #内容 编码(gzip )
Line-based text data: text/html # 基于行的文本数据
根据 以上信息,可以知道服务器使用HTTP/1.1 200 OK 响应了 客户端的请求。将信息 填入到报文格式中,如下
GET方法的HTTP响应报文格式
HTTP/1.1 | 空格 | 200 | 空格 | OK | \r | \n |
---|---|---|---|---|---|---|
Content-Type | : | text/html | \r | \n | ||
… | ||||||
Content-Encoding | : | gzip | \r | \n | ||
\r | \n | |||||
省略 |
下面 我们以HTTP-Post 为例,分析 POST 方法的 HTTP 请求和响应。打开 数据包,输入过滤条件ip.addr ==10.1.1.33, 显示 出的HTTP 中,Info列中还有POST 的即可 ,如下
我们 展开分析下
Hypertext Transfer Protocol #HTTP 协议
POST /hfs2_3b287/ HTTP/1.1\r\n # 请求行
Expert Info (Chat/Sequence): POST /hfs2_3b287/ HTTP/1.1\r\n #专家 信息
POST /hfs2_3b287/ HTTP/1.1\r\n
Severity level: Chat
Group: Sequence
Request Method: POST # 请求方法为 POST
Request URI: /hfs2_3b287/ # 请求 的URI
Request Version: HTTP/1.1 #请求 的版本
Host: 10.1.1.33:8080\r\n # 使用的主机
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r\n # 使用的浏览器类型
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n # 浏览器接受的类型
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r\n # 希望使用的语言
Accept-Encoding: gzip, deflate\r\n # 可使用的编码格式,这里是 gzip 和 deflate
Referer: http://10.1.1.33:8080/hfs2_3b287/\r\n #从 包含的URL 页面发起请求
Cookie: HFS_SID=0.248448607278988\r\n #Cookie信息
Cookie pair: HFS_SID=0.248448607278988
Authorization: Basic ZGVtbzpkZW1v\r\n #授权 证书信息
Credentials: demo:demo # 登录的用户名密码
Connection: keep-alive\r\n # 使用持久连接
Content-Type:multipart/form-data;boundary=---------------------------54542580413055\r\n # 请求的内容类型
Content-Length: 367\r\n # 包的长度
Content length: 367
\r\n # 空行
Full request URI: http://10.1.1.33:8080/hfs2_3b287/ # 请求的 URI 为http://10.1.1.33:8080/hfs2_3b287/
HTTP request 1/6
Response in frame: 3800 # 响应的帧号
Next request in frame: 3802 # 下一个请求的 正好
以上 就是使用POST 方法的 HTTP 请求包,可以看到请求的连接及登录的用户名密码等。将上面 的信息填入到报文格式中,如下
POST方法的HTTP请求报文格式
POST | 空格 | /hfs2_3b287/ | 空格 | HTTP/1.1 | \r | \n |
---|---|---|---|---|---|---|
Accept | : | text/html,application/xhtml+xml,application/xml | \r | \n | ||
… | ||||||
Content-Length | : | 367 | \r | \n | ||
\r | \n | |||||
忽略 |
另外 ,我们 在HTTP 的下面,看到了如下的内容
类型 的Multipart/form-data 是上传文件的一种方式。 Multipart/form-data 其实就是浏览器用表单上传文件的方式。最常见的情境是:在写邮件时,向邮件后添加附件,附件通常使用表单添加,也就是用 multipart/form-data 格式上传到服务器。我们 实验中向 服务器上传了一个文件,所以就是此类型。
在 看Wireshark中 的使用
首先看wireshark 中字段与 Multipart/form-data 的对应关系: MIME Multipart Media Encapsulation :代表整个 Multipart/form-data 上传文件中的数据。
Encapsulated multipart part :代表表单中不同部分的数据。
Boundary :用来隔开表单中不同部分的数据。
其次,
1) MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------54542580413055"
这行指出这个请求是 multipart/form-data 格式的,且 boundary 是 “----------54542580413055” 这个字符串。
2 )关于 Boundary : Boundary :用来隔开表单中不同部分的数据。实际上,每部分数据的开头都是由 “--”+boundary 开始的(这是 MIME 标准中讲述的标准内容)。
3 ) Encapsulated multipart part :紧跟着 boundary 的是该部分数据的描述:
Content-Dispostion:form-data;name="Filename"\r\n
每一个 part 至少一个 name 和一个 content 部分。
可以从 上面的multipart/form-data中 ,看到我们上传的文本名字为http-post.txt, 内容为“This is demo for HTTP POST”。
根据Wireshark 现实的响应包帧数,我们来看下第3800 帧 。
Hypertext Transfer Protocol #HTTP 协议
HTTP/1.1 200 OK\r\n # 响应行
Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n #专家 信息
HTTP/1.1 200 OK\r\n # 响应信息
Severity level: Chat
Group: Sequence
Request Version: HTTP/1.1 # 请求版本
Status Code: 200 # 状态码
Response Phrase: OK #响应 短语
Content-Type: text/html\r\n # # 响应包类似
Content-Length: 570\r\n # 响应包长度
Content length: 570
Accept-Ranges: bytes\r\n #服务器支持 的请求:字节
Server: HFS 2.3 beta\r\n #web 服务器类型
Content-Encoding: gzip\r\n # 实体数据的压缩格式
\r\n #空行
HTTP response 1/6 # 响应
Time since request: 0.008774000 seconds # 响应请求的时间
Request in frame: 3798 #请求 的帧号
Next request in frame: 3802 # 下一个请求的帧号
Next response in frame: 3804 # 下一个响应的 帧号
Content-encoded entity body (gzip): 570 bytes -> 866 bytes #内容 编码(gzip )
Line-based text data: text/html # 文本内容
以上 就是POST 方法的 HTTP 响应包,可以看到服务器向客户端发送了 HTTP/1.1 200 OK响应 了HTTP 请求包。服务器类型为HFS 2.3 beta, 将数据填入到报文格式中
POST方法的HTTP响应报文格式
HTTP/1.1 | 空格 | 200 | 空格 | OK | \r | \n |
---|---|---|---|---|---|---|
Server | : | HFS 2.3 beta | \r | \n | ||
… | ||||||
Content-Encoding | : | gzip | \r | \n | ||
\r | \n | |||||
省略 |
实验中我们 讲解了 主要的GET和POST 方法, 可以抓包 考虑, 学习其他的方法,动手提高能力 。
本文涉及相关实验:Wireshark数据抓包分析之HTTP协议
这个技术你学会了吗?加入网安实验室,1300+网安技能任你学!