010-基础入门-HTTP数据包&Postman构造&请求方法&请求头修改&状态码判断

知识点
HTTP/S数据包请求与返回
数据包请求和响应的简单模型如下:

以下是配置代理工具抓包时,进行请求和响应的模型

请求方法
常规请求-Get
Get请求数据包没有正文部分

用户登录-Post
Post请求数据包有正文部分,如用户登录请求

请求方法一览
| 请求方法 | 描述 | 主要特点与用途 |
|---|---|---|
| GET | 请求指定的资源。 | 用于获取数据,请求参数在 URL 中,不应有请求体。 |
| POST | 向指定资源提交数据。 | 用于创建新资源或提交数据(如表单、文件),数据在请求体中。可能导致状态变更。 |
| HEAD | 请求与 GET 相同的响应,但不返回响应体。 | 用于获取资源的元信息(如响应头),检查资源是否存在、是否被修改,更高效。 |
| PUT | 向指定位置上传其最新内容。 | 用于完整更新指定资源,客户端提供改变后的完整资源。 |
| DELETE | 请求服务器删除指定的资源。 | 用于删除服务器上的资源。 |
| OPTIONS | 返回服务器针对特定资源所支持的 HTTP 请求方法。 | 用于查询服务器支持的功能(如 CORS 预检请求)。 |
| TRACE | 回显服务器收到的请求。 | 用于测试或诊断,服务器将收到的请求内容返回给客户端。存在安全风险,通常被禁用。 |
| CONNECT | 建立一个到目标资源的隧道。 | 主要用于通过代理服务器建立 SSL 隧道(加密连接),例如用于 HTTPS。 |
- get:向特定资源发出请求(请求指定页面信息,并返回实体主体);
- post:向指定资源提交数据进行处理请求(提交表单、上传文件),又可能导致新的资源的建立或原有资源的修改;
- head:与服务器索与get请求一致的相应,响应体不会返回,获取包含在小消息头中的原信息(与get请求类似,返回的响应中没有具体内容,用于获取报头);
- put:向指定资源位置上上传其最新内容(从客户端向服务器传送的数据取代指定文档的内容),与post的区别是put为幂等,post为非幂等;
- trace:回显服务器收到的请求,用于测试和诊断。trace是http8种请求方式之中最安全的
- delete:请求服务器删除request-URL所标示的资源*(请求服务器删除页面)*
- option:返回服务器针对特定资源所支持的HTML请求方法 或web服务器发送*测试服务器功能(允许客户 端查看服务器性能);
- connect : HTTP/1.1协议中能够将连接改为管道方式的代理服务器
请求包头部常见解释和应用
请求头部字段常见解释

返回包状态码值解释和应用
Response状态码:
- 1xx:指示信息—表示请求已接收,继续处理。
- 2xx:成功—表示请求已经被成功接收、理解、接受。
- 3xx:重定向—要完成请求必须进行更进一步的操作。
- 4xx:客户端错误—请求有语法错误或请求无法实现。
- 5xx:服务器端错误—服务器未能实现合法的请求。
响应包状态码的应用
1、数据是否正常:状态码是否为2xx
2、文件是否存在:状态码是否为4xx
3、地址自动跳转:状态码是否为3xx
4、服务提供错误:状态码是否为5xx
注:对容错处理识别,如果状态码为3xx,则有如下可能
- 访问的网站资源不存在,自动跳转某个页面——文件不存在触发跳转
- 访问某个未授权文件时,自动触发跳转——文件存在但未授权触发跳转
常见响应包状态码
- 200 OK:客户端请求成功
- 301 redirect:页面永久性移走,服务器进行重定向跳转;
- 302 redirect:页面暂时性移走,服务器进行重定向跳转,具有被劫持的安全风险;
- 400 BadRequest:由于客户端请求有语法错误,不能被服务器所理解;
- 401 Unauthonzed:请求未经授权。
- 403 Forbidden:请求的资源存在,服务器收到请求,但是拒绝提供服务。
- 404 NotFound:请求的资源不存在,例如,输入了错误的URL;
- 500 InternalServerError:服务器发生不可预期的错误,无法完成客户端的请求;
- 503 ServiceUnavailable:服务器当前不能够处理客户端的请求

HTTP/S测试工具Postman使用
演示案例
数据-方法&头部&状态码
UA头-设备平台
Cookie-身份替换
见上图
案例-文件探针&登录爆破
页面正常访问
网站文件探针-Burp爆破管理员页面
使用后台扫描工具如御剑时,需要配置是否探测200、403、3xx,后台目录扫描工具原理正是利用响应状态码判断文件是否存在

在本地Win7虚拟机上搭建Zblog,测试访问如下所示

下面,我们测试使用Burp的Intruder模块对Z-blog网站目录进行爆破,找出管理员页面
使用Proxy模块抓包并发送至Intruder模块,配置Payload位置

配置Payload爆破字典
注意:
- 这里由于我们知道该网站目录结构,是不进行URL转码的,因此取消最下面的Payload Encoding勾选
- 这里由于我们是测试,实际上知道目录名称,所以在字典指向性极强

开始爆破,通过爆破结果状态码及响应长度可知管理界面目录为:
http://192.168.20.128/zblog/zb_system/login.php

后台登录爆破-Burp爆破管理员密码
下面使用Burp的Intruder模块对Z-blog网站登录页面爆破,找出管理员用户名和密码
在后台登录页面抓包,可知登录请求的数据包结构如下
