今天聚焦 HTTP 状态码、Cookie、Session、Token 机制将理论与动手观察结合并持续渗透安全思维。第一周·周四HTTP 状态码与 Cookie、Session、Token 机制 今日学习目标达成效果能独立说出HTTP 状态码的五大分类及每类代表含义并准确描述 200、301、302、304、400、403、404、500、502、503 等常见状态码的使用场景能用浏览器开发者工具快速定位一次请求的状态码、响应头中的Set-Cookie和请求头中的Cookie能用自己的话解释为什么 HTTP 是无状态的以及 Cookie/Session 如何解决状态问题能画出并讲解基于 Session 的认证流程和基于 Token 的认证流程能从安全视角指出 Cookie 的 HttpOnly、Secure 属性的作用以及 Session 劫持、CSRF 攻击与 Token 的关系能清晰回答“301 和 302 有什么区别”、“Token 为什么比 Session 更适合移动端”。 一、HTTP 状态码服务端对请求结果的“加密语言”每一个 HTTP 响应都会携带一个三位数字的状态码它能让客户端浏览器、爬虫、渗透工具立即了解请求的处理结果。1. 状态码分类状态码范围类别含义典型示例1xx信息性状态码请求已接收继续处理101 Switching ProtocolsWebSocket 升级2xx成功请求已成功被接收、理解、接受200 OK、201 Created、204 No Content3xx重定向需要客户端进一步操作才能完成请求301 永久重定向、302 临时重定向、304 Not Modified4xx客户端错误请求包含语法错误或无法被满足400 Bad Request、403 Forbidden、404 Not Found5xx服务器错误服务器在处理请求时发生错误500 Internal Server Error、502 Bad Gateway、503 Service Unavailable安全视角状态码本身就是信息泄漏的源头。例如403 可能告知攻击者“资源存在但没有权限”404 则可能说明资源不存在或路径错误302 可能泄露内部跳转逻辑500 报错可能爆出服务器路径、代码行数等敏感信息。在渗透测试信息收集阶段状态码分析是基础。2. 必须吃透的常见状态码200 OK请求成功正常返回数据。GET 返回所请求资源POST 返回操作结果。301 Moved Permanently永久重定向。服务器告知客户端请求的资源已被永久移动到Location头部指定的新 URL。浏览器会缓存这个重定向后续请求旧地址时直接使用新地址不再询问服务器。搜索引擎也会将权重转移到新 URL。302 Found或Moved Temporarily临时重定向。资源只是暂时移动到新 URL客户端不应该缓存下一次请求仍应访问原 URL。常用于未登录用户跳转到登录页登录后再跳回。304 Not Modified客户端发送带If-Modified-Since或If-None-Match头的条件请求服务器确认资源未修改返回 304 且不带响应体客户端可直接使用本地缓存。大幅提升性能。400 Bad Request客户端请求有语法错误服务器无法理解。比如请求头过大、格式错误。403 Forbidden服务器理解了请求但拒绝执行。通常权限不足但资源存在与 401 不同401 表示需要认证。404 Not Found请求的资源不存在。渗透中常通过访问某些敏感路径如/admin判断是否为 403 或 404以此猜测后端目录结构。500 Internal Server Error服务器内部处理出错通常由代码异常、配置错误等引发。攻击者可能通过构造异常输入触发 500从而推断注入点或服务端语言。502 Bad Gateway作为网关或代理的服务器从上游服务器收到无效响应。常出现在 Nginx 反向代理后端服务宕机时。503 Service Unavailable服务器暂时无法处理请求过载或维护通常过一段时间恢复。运维保障需关注。3. 重定向的实战观察打开浏览器开发者工具 Network 面板勾选“Preserve log”访问一个会自动跳转的 HTTP 站点如许多网站会将 http 跳转到 https你会看到第一个请求返回301 或 302响应头包含Location: https://...浏览器紧接着自动发起第二个请求到新 URL状态码 200。尝试用 curl 分别观察 301 和 302curl -v http://某个会重定向的地址加上-L参数看自动跟随。 二、Cookie解决 HTTP 无状态的小标签为什么需要 CookieHTTP 本身不保存任何请求间的关系服务器不能自动识别“刚才请求页面的用户”与“现在登录的用户”是同一个人。Cookie 是服务器委托浏览器保存在客户端的一小段文本数据下次请求同一站点时浏览器会自动带上它从而让服务器能识别连续会话。1. Cookie 的工作流程客户端首次请求服务器如登录页面。服务器验证用户身份后在响应中加入Set-Cookie头部Set-Cookie: sessionidabc123; Path/; HttpOnly; Secure浏览器收到该头部会将sessionidabc123及其属性存入本地 Cookie 存储区。之后客户端每次请求该域时浏览器都会在请求头自动附加Cookie: sessionidabc123。服务器读取 Cookie 中的 sessionid到服务端存储中查找对应的用户信息识别用户身份。2. Cookie 的关键属性安全相关Domain / Path限定 Cookie 的作用域。若 Domain 设置过宽可能引发安全隐患比如子域名之间不必要地共享 Cookie。Expires / Max-Age控制 Cookie 有效期未设置则为会话 Cookie关闭浏览器即失效。HttpOnly极其重要。若设置为 true浏览器将禁止 JavaScript如document.cookie读取该 Cookie。这是防御 XSS 窃取会话 Cookie 的第一道防线。Secure若设置为 true浏览器只会在 HTTPS 加密连接上传输该 Cookie防止中间人嗅探。SameSite防御 CSRF 攻击的新属性。SameSiteStrict禁止所有跨站请求携带 CookieSameSiteLax允许部分如导航链接携带None则无限制需配合 Secure。安全视角总结没有 HttpOnly 的会话 Cookie 一旦被 XSS 攻击获取攻击者就能接管用户会话。没有 Secure 的 Cookie 在 HTTP 下可能被 ARP 欺骗等手段截获。SameSite 属性可直接削减 CSRF 攻击面但老版本浏览器可能不支持。 三、Session服务端维护的用户会话1. 原理Session 是一种服务端的状态保持方案。用户登录后服务器生成一个全局唯一的 SessionID随机、不可预测并建立一块内存/数据库空间保存该 ID 对应的用户信息。然后将 SessionID 通过Set-Cookie发送给浏览器浏览器每次请求带着这个 SessionID服务器用它查找会话数据。典型流程用户提交登录表单 → 服务器验证密码 → 创建 Session存储user_id、角色等信息 → 响应Set-Cookie: SESSIONID随机串后续请求浏览器自动带 Cookie → 服务器根据 SessionID 查找 Session 数据确认用户身份。2. 常见安全风险Session 劫持攻击者通过 XSS、网络嗅探、日志泄露等方式获取他人 SessionID并在自己浏览器中伪造 Cookie冒充用户。防御HttpOnly、Secure、HTTPS、及时销毁过期 Session。Session 固定攻击攻击者先获取一个合法 SessionID如访问网站获得然后诱导受害者使用这个固定的 ID 登录如通过 URL 传递之后攻击者就可以用此 ID 访问受害者的会话。防御用户登录后立即更换 SessionID。Session 过期与销毁没有及时注销的 Session 可能被复用需要设置合理超时和手动登出时清除服务端会话。 四、Token 认证无状态的身份证明对于移动端、前后端分离、微服务等场景Session 存在扩展性差、不适合跨域等问题。Token 是一种更灵活的方案尤其是JWTJSON Web Token。1. Token 工作原理用户登录成功后服务器根据用户信息、过期时间等生成一个 Token并用密钥对其进行签名或加密。Token 本身包含了用户身份信息自包含。服务器将 Token 直接返回给客户端通常放在响应体 JSON 中。客户端保存 Token如 localStorage、移动端本地存储并在后续请求中将 Token 放在Authorization头部Bearer Token或 POST 参数中。服务器收到 Token 后只需验证签名是否有效、是否过期而无需查询数据库或会话存储即可识别用户。因此它是无状态的。2. JWT 结构JWT 由三段 Base64 字符串组成用.分隔Header声明类型和签名算法如{alg:HS256,typ:JWT}。Payload存放实际数据用户 id、过期时间、签发者等称为声明Claims。注意Payload 仅 Base64 编码非加密任何人可见绝不能存放密码等敏感信息Signature使用 Header 中声明的算法对 Header 和 Payload 进行签名防止篡改。3. 为什么 Token 比 Session 更适合移动端扩展性Session 存储在服务器内存或数据库大型分布式架构需要共享 Session增加复杂度。Token 自包含任何服务实例只要能验证签名就可识别用户更契合无状态的 API 设计。跨域便捷Cookie 受同源策略和域名限制移动端或跨域 API 调用不一定走浏览器 Cookie 机制Token 放在 Header 中天然跨域。无需依赖浏览器移动 App 没有浏览器那样的 Cookie 自动管理手动管理 Token 更直接也可安全存储于设备安全区域。多服务适配微服务架构中每个服务仅需公钥即可验签 Token无需集中式会话存储。4. Token 的安全注意签名密钥必须高强度保护若对称密钥泄露攻击者可伪造任何用户 Token。Payload 加密不是必选项必要时可使用 JWE加密 JWT或内部加密但常见实现仍是签名而非加密务必不要让 JWT 承载密码。存储位置浏览器端若将 Token 存于 localStorage 可能遭受 XSS 窃取存于 HttpOnly Cookie 又无法自定义 Authorization 头需要权衡。最佳实践中可使用 BFF 模式或使用仅 HttpOnly 的 Cookie 但仍携带 CSRF Token。过期与刷新设计短期有效的 Access Token 和长期 Refresh Token减少泄露风险。✍️ 五、动手实践用开发者工具和 curl 观察状态码、Cookie实践 1追踪一次重定向的状态码打开终端访问一个已知会跳转的 URL建议自己搭建或使用公开测试站curl-vhttp://www.baidu.com21|grep-EHTTP|Location你会看到服务器返回HTTP/1.1 302 Found和Location: ...。加上-L再试试curl -L -v http://www.baidu.com观察是否自动跟随。实践 2观察 Set-Cookie 和 Cookie 发送打开浏览器隐私窗口F12 → Network → 勾选“Preserve log”。访问一个需要登录的网站例如http://testphp.vulnweb.com这类练习站先观察首页的响应头可能会看到Set-Cookie设置会话。输入任意用户名密码提交登录或注册观察登录请求的响应查找Set-Cookie中设置的会话 ID。登录后刷新页面观察此时请求头中的Cookie字段已自动带上之前设置的会话 ID。重点检查Set-Cookie 是否带有HttpOnly和Secure标志。实践 3手动模拟 Set-Cookie 与 Cookie 发送用 curl 手动携带 Cookiecurl-v-bsessionidabc123http://example.com查看请求头是否出现Cookie: sessionidabc123。 六、课后测试题与解析测试题 1301 和 302 重定向有什么区别分别适用于什么场景参考答案301 永久重定向表示资源已被永久移动到新地址。浏览器会缓存此重定向信息之后对原 URL 的请求会自动转为新 URL不再询问服务器。搜索引擎也会将权重转移到新 URL。适用于网站域名永久迁移、HTTP 永久升级到 HTTPS。302 临时重定向表示资源只是临时移动到新地址。浏览器不应缓存下次请求还会发送到原 URL 让服务器再次决策。适用于网站维护时的临时跳转、未登录用户重定向到登录页登录后返回原页面不能缓存。安全角度补充302 曾被一些攻击利用如 302 跳转劫持现在很多浏览器为避免歧义对 302 的实际缓存行为趋于保守。测试题 2为什么 Token 认证比 Session 更适合移动端应用参考答案无状态Token 自包含用户信息服务器不需要存储会话数据轻松水平扩展适合移动端后端常见的分布式 API 服务。跨域通用Token 放在 HTTP Header 中不受浏览器同源策略及 Cookie 域名限制适合移动 App 和各种跨域 API 调用。不依赖浏览器 Cookie 机制移动 App 没有自动管理 Cookie 的能力使用 Token 手动存放和发送更清晰可控也能利用设备安全存储如 Keychain。性能省去服务端查数据库/缓存获取会话的步骤只验签即可减少延迟。但也要注意移动端的 Token 安全存储问题以及必须使用 HTTPS 防止令牌被窃。✅ 今日学习效果自检清单我能默写 5 类状态码范围及含义并举例说明每类的典型状态码我能解释 301 和 302 的关键区别缓存与否我知道 403 与 401 的差异已认证但无权 vs 未认证我能画出基于 Cookie 的 Session 认证流程登录→Set-Cookie→后续请求带 Cookie我明白 HttpOnly 和 Secure 属性分别防御什么攻击XSS 窃取、中间人嗅探我能对比 Session 和 Token 的优缺点说出 Token 适合移动端的原因我在 Network 面板中成功找到 Set-Cookie 和 Cookie 头部并观察到重定向的状态码⚠️ 阶段避坑重点不要混淆 301 和 302 的缓存行为面试常考实战中不正确使用会引发 SEO 或功能问题。不要把“Token 更适合移动端”理解成“Token 绝对安全”Token 也需要防泄漏、防重放且不应在 Payload 存放隐私信息。不要忽略 Cookie 属性看响应头时务必检查 HttpOnly 和 Secure这是你以后做安全审计的基本功。不要死记状态码数字要结合场景理解。比如看到 304你要知道这是缓存相关看到 502知道是网关错误通常后端服务挂了。明天周五我们将学习Wireshark 抓包实操把今天学到的状态码、Cookie、重定向全部放到真实抓包环境里验证用数据包还原整个交互过程请务必保留一些实验用的网站或今天的请求记录。