第10天：基础入门-HTTP数据包&Postman构造&请求方法&请求头修改&状_笔记｜web安全｜渗透测试｜网络安全_2023-2024

一、基础入门

1. 请求与返回过程00:25

• 基本流程：浏览器发送Request请求到服务器，服务器通过Response返回数据给浏览器
• 代理流程：请求先发给代理（如抓包工具），代理选择性转发/丢弃请求，响应也经过代理返回
• 请求方向：Request代表发送方，Response代表接收方
• 代理作用：在请求过程中加入中间层，用于拦截和分析数据包
• 典型工具：Burp Suite等抓包工具就是通过建立代理服务器实现抓包

2. HTTP数据包结构01:33

1）GET请求方式

• 组成结构：
  • 请求行：包含请求方法(GET)、URL、HTTP版本
  • 请求头：包含Host、User-Agent、Accept等字段
  • 空行：分隔头部和正文
  • 正文：GET请求通常没有正文
• 特点：用于请求指定页面信息，参数通过URL传递

2）POST请求方式01:48

• 组成结构：
  • 请求行：包含请求方法(POST)、URL、HTTP版本
  • 请求头：包含Content-Type、Content-Length等字段
  • 空行：分隔头部和正文
  • 正文：包含提交的表单数据
• 特点：用于提交数据处理请求，可能导致资源修改

3）请求方法对比

• GET：请求指定资源，参数在URL中
• POST：提交数据，可能导致资源修改
• HEAD：类似GET但只返回头部信息
• PUT：上传最新内容（幂等操作）
• DELETE：请求删除指定资源
• OPTIONS：测试服务器功能
• CONNECT：建立管道连接

3. 应用案例02:06

1）例题：方法头部状态码应用

• 工具选择：
  • 初学者可使用Burp Suite
  • 专业人员可直接使用浏览器开发者工具
• 分析步骤：
  • 配置代理服务器（如127.0.0.1:8080）
  • 拦截请求数据包
  • 分析请求方法和头部信息
  • 区分GET和POST请求的特征差异
• 实际案例：
  • 搜索请求通常使用GET方法
  • 登录请求通常使用POST方法
  • 可通过Content-Type区分表单提交类型

4. HTTP/S测试工具Postman使用09:37

1）HTTP请求头部10:47

• 请求头部的常见解释11:21
  • Host：指定请求的服务器域名
  • User-Agent：客户端浏览器信息
  • Accept：客户端可接收的内容类型
  • Cookie：存储的会话信息
  • Content-Type：请求体的MIME类型
    Referer：请求来源页面
• • 注：本笔记严格根据课程内容整理，保留了所有关键知识点和实际案例，采用康奈尔笔记法结构化呈现，确保内容完整性和准确性。

二、基础入门20:02

1. 修改cookie21:41

• 身份验证机制：Cookie是HTTP头部中用于判断用户身份的关键字段，通过对比登录前后的数据包可以观察到Cookie的变化。
• 实验验证：
  • 未登录状态下访问后台页面会返回"没有权限"提示
  • 登录后数据包中Cookie字段会新增"username=xxx"等身份凭证信息
  • 将登录后的Cookie复制到未登录的数据包中，可以绕过登录直接访问后台
• 安全意义：演示了Cookie作为身份凭证的重要性，篡改可能导致越权访问

2. 用户身份凭据26:39

• 凭证类型：
  • Cookie：最常见的身份凭证存储方式
  • JWT：基于Token的验证机制
  • Session：服务器端会话管理
• 特征对比：
  • 登录前后Cookie内容会发生明显变化
  • 其他HTTP头部信息（如UA）通常保持不变
• 安全测试应用：修改凭证字段可以测试系统的身份验证机制是否健全

3. 应用案例30:12

1）例题:数据包不一致

• 问题场景：
  • 漏洞存在于特定客户端（如APP）的特定功能中
  • 直接通过浏览器访问可能无法触发漏洞
• 解决方案：
  • 抓取APP原始请求数据包
  • 在测试工具中完整复现数据包格式
  • 重点保持Cookie、UA等关键字段一致
• 核心原理：
  • 服务器可能通过UA等字段区分客户端类型
  • 某些功能可能只在特定客户端中可用
  • 数据包格式不匹配会导致请求被拒绝或重定向

4. 状态码33:05

1）200状态码33:36

• 定义：HTTP状态码200表示请求已成功处理，服务器正确接收并理解了请求内容
• 典型场景：
  • 访问存在的网页文件（如index.php）
  • 数据正常传输且服务器能正确解析
• 判断依据：
  • 浏览器开发者工具Network标签显示"200 OK"
  • 数据包捕获工具显示响应头包含"200"状态
• 特点：
  • 表示请求路径正确且资源存在
  • 服务器与客户端通信正常
  • 是大多数成功请求的返回状态

2）404状态码34:56

• 定义：表示请求的资源在服务器上不存在
• 触发条件：
  • 访问不存在的文件路径（如错误的URL）
  • 输入错误的文件名或扩展名
• 典型表现：
  • 服务器收到请求但找不到对应资源
  • 属于4xx客户端错误类别
• 实际案例：
  • 访问不存在的index文件时返回404
  • 拼写错误的URL路径导致404
• 与200的区别：
  • 200表示资源存在且可访问
  • 404明确指示资源不存在

3）403状态码36:34

• 核心特征：表示服务器理解请求但拒绝执行
• 文件夹检测：
  • 访问存在的文件夹但无索引文件时返回403
  • 不同于404（资源不存在），403是资源存在但禁止访问
• 特殊场景：
  • 当文件夹存在默认索引文件（如index.php）时返回200
  • 删除索引文件后相同路径返回403
• 权限说明：
  • 常见于目录浏览被禁用的情况
  • 与文件权限设置无直接关系
• 判断逻辑：
  • 文件存在→200
  • 文件不存在→404
  • 文件夹存在但无索引→403

4）500或401状态码40:18

• 5xx服务器错误
  • 本质：服务器内部处理请求时发生错误
  • 不确定性：
    • 无法确定请求资源是否存在
    • 可能是配置错误或代码异常导致
  • 典型场景：
    • 服务器解析资源失败
    • 后端服务不可用
• 3xx重定向
  • 双重性：
    • 可能是资源存在的主动跳转
    • 也可能是资源不存在的容错跳转
  • 实现方式：
    • 代码级跳转（特定文件触发）
    • 全局配置（错误路径统一跳转首页）
  • 判断难点：
    • 无法通过状态码直接确定资源存在性
• 401未授权
  • 认证要求：
    • 需要提供有效凭证才能访问
    • 常见于密码保护区域
  • 与403区别：
    • 403是认证后仍无权限访问

5）应用案例43:12

• 文件探针演示
  • 工具原理
    • 状态码判断：通过HTTP响应状态码（如200、403、404等）判断文件或目录是否存在
    • 字典扫描机制：工具会加载路径字典，依次尝试访问不同路径并分析返回状态码
    • 误报处理：工具通常默认只勾选200等明确存在的状态码，避免因302等跳转状态产生误报
  • 操作演示
    • Burp Suite配置：
      • 抓取目标网站请求包
      • 在路径位置设置变量点（如/path/§test§）
      • 加载路径字典文件（包含/system/、/login.php等常见路径）
    • 线程控制：建议设置5个线程进行扫描，避免对服务器造成过大压力
    • 编码问题处理：需关闭自动URL编码功能，否则/会被转码为%2F导致路径识别错误
  • 状态码解析
    • 200响应：明确表示文件存在（如/zb_system/目录）
    • 302响应：可能存在跳转，需要进一步验证
    • 403/404响应：明确表示路径不存在（如/user/目录返回403）
    • 误判案例：当/zb_user/路径被误写为/user/时会产生错误判断
  • 实验验证
    • 有效路径：/index.php返回200，/login.php返回302跳转
    • 无效路径：/db1/、/123456/等随机路径均返回404
    • 路径规范：必须确保路径中包含正确的反斜杠（如/zb_system/不能写成zb_system）
  • 工具对比
    • 专业扫描工具：内置更完善的路径字典和状态码处理逻辑
    • Burp Suite：需要手动配置但灵活性更高，适合定制化扫描
    • 共同原理：都是通过修改请求路径+分析状态码来判断资源存在性
• 例题：登录包爆破56:34
  • 爆破原理与流程
    • 双字段验证机制：登录时需要同时修改明文密码字段和加密密码字段，两者都正确才能成功登录。测试发现仅修改其中一个字段会导致500服务器错误。
    • 状态码判断依据：成功登录返回302跳转状态码，失败则返回500错误状态码，这是判断爆破是否成功的关键指标。
    • 加密特征识别：通过分析数据包中同时存在的明文和密文字段，可判断系统采用MD5加密方式（如明文"123456"对应密文"e10adc3949ba59abbe56e057f20f883e"）。
  • 爆破工具操作步骤
    • 数据包捕获：
      • 使用Burp Suite拦截登录请求包
      • 重点标记username、password明文和加密字段
      • 测试发现password字段需要双重验证（明文+MD5密文）
    • 字典配置：
      • 准备明文密码字典（如：123456,1234567,a123,a123456等）
      • 使用Payload Processing自动将明文转为MD5格式
      • 设置双变量替换：明文password字段和加密password字段同步替换
    • 结果验证：
      • 通过响应状态码筛选302跳转的请求
      • 检查对应payload的密文值（如"5690dde…"）
      • 反向查找该密文对应的明文密码即为正确密码
  • 实战技巧
    • 字段优先级：测试发现加密字段验证优先级高于明文字段，当加密字段正确时即使明文字段错误也能登录成功
    • 错误处理：遇到500错误时可尝试重启服务或重新抓包，避免因服务异常导致误判
    • 自动化设置：使用Burp Suite的Intruder模块时：
      • 选择"Cluster bomb"攻击模式处理多变量
      • 在Payload Processing中添加"Hash->MD5"转换规则
      • 通过"Grep Extract"自动标记302响应
  • 注意事项
    • 加密一致性：必须确保字典中的每个密码都经过完全相同的加密流程，否则会导致爆破失败
    • 性能优化：
      • 优先测试高频弱口令（如admin/123456）
      • 合理控制线程数防止被封禁
      • 使用条件过滤快速排除无效尝试
    • 法律边界：该技术仅限授权测试使用，未经许可的爆破行为可能涉及违法

5. postman介绍01:06:48

1）工具定义与用途

• API测试工具: 一款用于在线测试API接口的专业工具，主要用于HTTP请求的发送和响应分析
• 发包功能: 支持从零开始构建完整的数据包，相比抓包修改更灵活，可完全自定义请求内容
• 应用场景: 后期API安全测试、HTTP请求测试、接口功能验证等场景的必备工具

2）基本功能演示

• 请求构建:
  • 支持新建HTTP请求，设置请求地址(如后台路径)
  • 可选择GET/POST等请求方法
  • 可自定义请求头部(Headers)，包括User-Agent等参数
• 响应分析:
  • 显示返回包内容，支持预览/源代码/美化代码三种查看方式
  • 示例：未带cookie请求返回"无权限"，带cookie后成功进入后台

3）核心测试功能

• Cookie测试:
  • 通过添加/删除cookie值验证权限控制
  • 示例：从已登录页面获取cookie后，带cookie请求后台页面
• 批量测试:
  • 可创建多个请求组成测试序列(如先登录再访问后台)
  • 支持文件夹形式组织请求，批量运行测试用例
• UA模拟:
  • 修改User-Agent可测试不同客户端响应
  • 示例：添加手机UA后访问百度，返回m.baidu.com移动端页面

4）与BurpSuite对比

• 优势对比:
  • Postman：更智能的API测试，内置授权管理等专业功能
  • BurpSuite：集成抓包/改包功能，更适合安全测试
• 使用建议: 根据测试需求灵活选择，Postman更适合纯API测试场景

5）高级功能提示

• 授权操作: 支持多种身份验证方式配置
• 头部管理: 可方便地添加/修改/隐藏请求头部
• Body编辑: 专门处理POST提交的数据内容，适合测试POST注入等场景

6. 数据包结构与安全测试01:15:33

1）数据包构成与访问机制

• 请求包与响应包：包含请求包(request)和响应包(response)两种类型，需要理解其结构差异和对应关系
• 访问异常案例：部分网站电脑直接访问会失败，必须携带特定数据包才能正常打开（如后续SQL注入案例）
• 工具使用差异：直接通过URL注入(
  http://example.com?id=1http://example.com?id=1http://example.com?id=1
  )与导入数据包文件注入(
  sqlmap−rpacket.txtsqlmap -r packet.txtsqlmap−rpacket.txt
  )可能产生不同结果

2）SQL注入实战案例

• 失败场景：使用
  sqlmap−u"http://example.com?id=1"sqlmap -u "http://example.com?id=1"sqlmap−u"http://example.com?id=1"
  测试时显示漏洞不存在
• 成功方法：
  • 导出原始访问数据包
  • 改用
    sqlmap−rpacket.txtsqlmap -r packet.txtsqlmap−rpacket.txt
    方式注入
• 根本原因：直接URL访问会采用工具默认请求头，而数据包注入会保留原始请求头信息

3）数据包关键特性

• 唯一性要求：部分安全测试必须使用特定数据包才能复现漏洞（如缺少特定头部字段会导致访问失败）
• 可修改性应用：通过修改/增加数据包内容进行安全测试（如添加注入参数、修改请求方法等）
• 典型场景：
  • 网站访问异常排查
  • 漏洞复现与验证
  • 绕过安全检测机制

4）抓包问题排查

• 常见问题：抓包时网站跳转百度/无法访问
• 故障原因：
  • 证书未正确安装（需同时安装到"中间人颁发机构"和"受信任根证书"）
  • 浏览器安全策略限制
  • 网站双重证书校验机制
• 解决方案：
  • 检查BurpSuite等工具证书安装完整性
  • 调整浏览器安全设置
  • 更换不校验证书的测试网站

5）请求方法与测试场景

• GET请求：常规网页访问、参数传递
• POST请求典型场景：
  • 文件上传功能
  • 用户登录认证
  • 表单数据提交
• 其他头部字段：
  • Cookie：身份认证凭据
  • User-Agent：客户端系统/浏览器识别
  • Host：服务器域名标识

6）安全测试思维导图

• 检测方向：
  • 状态码分析（如500服务器错误）
  • 请求方法验证
  • 头部字段篡改测试
• 测试要点：
  • 数据包完整性校验
  • 参数边界测试
  • 异常数据处理

三、知识小结