步骤
打开靶场
根据题目得知需要admin身份获取flag
打开bp进行抓包
admin=0时，页面回显为访客（guest），说明 **0在该字段中代表 “非管理员” 身份 ，是服务器定义的权限否定值；由此可反向推导，服务器大概率会用一个对立值代表 “管理员” 身份，这是完成权限伪造的基本逻辑。
发送到Reoeater
将Cookie部分admin=0该为admin=1，获取到flag
在 Web 开发和 CTF 渗透场景中，数字 0 和 1 是最常用的布尔型权限标识，遵循 “0 为假（False）、1 为真（True）”的通用逻辑：0 代表无对应权限、非目标身份，1 代表拥有对应权限、是目标身份。这种设计简单且常见，在 CTF 的 Cookie 欺骗题目中，将权限标识的 0 改为 1 是最直接、最高概率成功的尝试
知识点讲解
Cookie 与 Session
一、Cookie 官方定义与技术原理
Cookie 是由 RFC 6265 定义的、由 Web 服务器生成并通过 HTTP 响应头下发至客户端浏览器，存储在客户端本地的小型文本数据片段，是 HTTP 无状态协议下实现客户端与服务端状态保持的核心机制之一。Cookie 由服务端创建，浏览器负责存储、管理与自动携带，其本质是服务端与客户端之间传递状态信息的标准化载体，不具备主动执行代码的能力，仅作为纯文本数据参与 HTTP 通信流程。 从 HTTP 协议交互层面，Cookie 的生成与传递遵循严格规范：当客户端首次向服务端发起 HTTP 请求时，服务端可在响应头中添加 Set-Cookie 字段，该字段包含 Cookie 名称、值、作用域、有效期、安全属性、访问限制等配置信息；浏览器接收到该响应头后，会按照协议规则解析并持久化或临时存储 Cookie 数据；在后续同域名、同路径的 HTTP/HTTPS 请求中，浏览器自动在请求头中添加 Cookie 字段，将匹配的 Cookie 数据回传至服务端，服务端通过解析请求头中的 Cookie 数据，识别客户端身份与历史交互状态，从而弥补 HTTP 协议本身无状态的特性缺陷。 Cookie 具备明确的存储与传输约束：单条 Cookie 数据容量通常限制在 4KB 以内，单个域名下可存储的 Cookie 数量存在浏览器厂商自定义上限，一般为 50 条左右。其核心属性包含：Name（名称）与 Value（值）为基础键值对，存储实际业务数据；Domain（域名）限定 Cookie 生效的域名范围，仅当前域名及子域名可访问；Path（路径）限定 Cookie 生效的 URL 路径；Expires 与 Max-Age 定义 Cookie 生命周期，分为会话级 Cookie（浏览器关闭即销毁）与持久化 Cookie（到达指定时间后失效）；Secure 为安全标识，仅在 HTTPS 加密连接下传输；HttpOnly 限制客户端 JavaScript 脚本访问，防范 XSS 攻击窃取 Cookie；SameSite 用于防范 CSRF 跨站请求伪造，控制跨站场景下 Cookie 的携带规则。 Cookie 的应用场景以客户端状态记录为主，包括用户身份标识、登录状态持久化、页面个性化配置、用户行为追踪、广告投放归因、购物车临时存储等，但其存储在客户端的特性决定了数据安全性较低，易被用户查看、修改、删除或伪造，因此不适合存储敏感业务数据。
二、Session 官方定义与技术原理
Session 即会话，是服务端为单个客户端浏览器创建的、独立的临时数据存储对象，是服务端维护用户会话状态的核心机制。Session 运行于服务端内存、文件系统、缓存中间件（如 Redis、Memcached）或数据库中，与客户端无直接数据存储关系，其核心作用是在一次用户访问周期内，集中存储用户专属状态数据，实现跨请求的状态关联与数据共享。 Session 的生命周期由服务端严格管控：当客户端首次请求服务端时，服务端校验客户端未携带有效会话标识，自动创建全新 Session 对象，分配全局唯一的 Session ID（会话标识符），该 ID 通常为随机加密字符串，具备唯一性与不可预测性；服务端将用户相关状态数据存储至对应 Session 对象中，并通过 Set-Cookie 响应头将 Session ID 下发至客户端，客户端以 Cookie 形式临时存储该 Session ID；后续客户端发起请求时，通过 Cookie 将 Session ID 回传服务端，服务端根据 ID 检索对应的 Session 数据，完成用户身份验证与状态恢复。 Session 具备明确的失效机制与管理规则：默认情况下，Session 为会话级生命周期，客户端浏览器关闭后，存储 Session ID 的 Cookie 销毁，服务端 Session 数据在超过超时时间（通常为 15～30 分钟，可配置）后自动回收释放；服务端支持主动销毁 Session，如用户执行退出登录操作时，服务端立即清除对应 Session 数据；在分布式部署架构下，单服务端存储 Session 存在共享问题，需通过 Session 复制、集中式缓存、令牌化转换等方案实现多节点会话同步。 与 Cookie 相比，Session 存储容量无固定协议限制，仅受服务端资源配置约束，且数据存储于服务端，客户端无法直接修改原始数据，安全性显著高于 Cookie，适合存储用户登录凭证、权限信息、表单进度、敏感业务状态等核心数据。但 Session 依赖服务端资源存储，大量用户并发访问时会占用服务端内存与存储资源，对服务端性能与扩展性存在一定影响。
三、Cookie 与 Session 官方对比与关联机制
从技术本质来看，Cookie 是客户端存储载体，Session 是服务端会话对象，二者并非对立关系，而是 HTTP 状态保持机制中协同工作的核心组件，Session 依赖 Cookie 完成 Session ID 的传递，是最主流、最标准的会话实现方式。 在存储位置上，Cookie 存储于客户端浏览器本地，属于客户端侧状态管理方案；Session 存储于服务端，属于服务端侧状态管理方案。在数据安全性上，Cookie 数据暴露在客户端，易被窃取、篡改，仅适合存储非敏感公开数据；Session 数据封闭在服务端，仅传输加密标识，安全性更高，适合存储敏感核心数据。在数据容量上，Cookie 受 4KB 大小限制，存储能力有限；Session 容量由服务端资源决定，支持大容量数据存储。在生命周期上，Cookie 可通过配置实现长期持久化，跨浏览器重启仍有效；Session 依赖客户端会话与服务端超时配置，默认会话关闭或超时后失效。在服务端资源消耗上，Cookie 不占用服务端存储资源，对服务端压力极小；Session 持续占用服务端资源，并发量越大资源消耗越高。 二者共同构成 Web 应用会话管理的基础体系，Cookie 解决状态数据的客户端存储与传输问题，Session 解决敏感状态数据的服务端安全存储与管理问题，二者结合实现了安全、高效、标准化的用户状态保持能力，是现代 Web 登录认证、权限控制、业务交互的底层技术支撑
四、Cookie 与 Session结合使用
在基于 HTTP 协议的 Web 应用体系中，HTTP 本身属于无状态协议，服务器无法天然识别多次请求是否来自同一客户端。为实现用户会话保持、身份认证、状态管理等功能，Cookie 与 Session 采用协同工作模式，构成现代 Web 会话管理的标准实现方案。二者并非相互替代，而是客户端标识传递与服务端状态存储的互补机制。
1.Session 负责在服务端存储用户状态数据，包括登录信息、权限、会话数据、临时业务数据等。 2.Cookie 负责在客户端存储并传递唯一的 Session ID，作为客户端与服务端之间的关联凭证。 3.服务端通过客户端提交的 Session ID 定位对应的 Session 对象，从而恢复用户会话状态。
这种模式既保证了数据安全性（真实数据存在服务端），又保证了通信轻量化（仅传输标识符），是 Web 认证体系的基础架构。
