如何防止cookie劫持

凌晨三点，何防我在调试一个电商网站时，何防亲眼看着自己的何防管理员会话被一个陌生IP接管。那个攻击者只用了不到两分钟，何防就通过XSS漏洞拿到了我的何防Cookie，然后像回自己家一样逛遍了后台数据库。何防那次之后我养成了个习惯——每次登录任何重要系统，何防都会先按F12看一眼网络请求里的何防Cookie属性。

Cookie劫持的何防本质就是身份盗窃。你登录网站后，何防服务器发给你一串随机字符当作通行证，何防这串字符就是何防Cookie。攻击者要做的何防不是破解你的密码，而是何防直接偷走这张通行证。2017年Uber数据泄露事件里，何防攻击者就是通过GitHub上的员工账号顺藤摸瓜，最终窃取了云端密钥，而普通用户的会话Cookie更是像超市门口无人看管的购物车一样容易推走。

防劫持的第一道防线是让Cookie“绑死”在特定设备上。你可以给Cookie设置一个指纹参数，比如把用户代理字符串、屏幕分辨率、时区这些浏览器特征混合加密后写入Cookie。当服务器收到请求时，先比对当前请求头里的指纹信息是否和Cookie里的一致——不一致就直接踢下线。这个方法不完美，毕竟有些企业内网用户共用同一台代理服务器，指纹会撞车，但对个人用户来说足够有效。

第二招是压缩Cookie的生命周期。别让会话Cookie动辄存活半个月，那等于给攻击者留了充足的作案时间。我见过一些政府网站，登录状态能保持三十天，这种设计简直是在邀请黑客来喝茶。合理的做法是让会话Cookie在浏览器关闭时立即失效，再配合一个独立的“记住我”令牌，这个令牌单独存储、单独校验，并且每七天强制轮换一次。就算主Cookie被偷，攻击者拿到的也只是一串过期字符。

还有一招容易被忽略——把Cookie的HttpOnly属性打开。这行代码写起来就一句话，但能直接封死JavaScript读取Cookie的路径。很多XSS攻击就是靠注入脚本去document.cookie里掏东西，HttpOnly一开，他们只能看着那串乱码干瞪眼。我自己写代码时还会额外检查SameSite属性，把它设为Lax或Strict，这样跨站请求就不会自动带上Cookie，CSRF攻击的难度会陡增。

光靠被动防御不够，你得像盯监控录像一样盯着Cookie的异常使用模式。给Cookie加个计数器，比如每个会话最多允许使用二十次，超过就强制重新认证。或者记录每次请求的IP地理位置，如果五分钟前还在北京登录，现在突然从洛杉矶发来请求，那这Cookie九成是被人复制走了。这种主动检测机制不需要多复杂的算法，简单的规则引擎就能拦截大部分劫持尝试。

最后说个反直觉的观察——很多人死于过度信任HTTPS。他们觉得网址栏挂了把锁就万事大吉，实则中间人攻击照样能通过伪造证书或DNS劫持来窃取传输中的Cookie。我建议在敏感操作时额外加一层设备验证，比如登录后修改密码或支付前，让服务器发送一次性验证码到绑定手机。这招虽然老土，但至今仍是拦截会话劫持最有效的手段之一。

Cookie劫持不是那种能一劳永逸解决的问题。攻击手法在进化，防御手段就得跟着迭代。我见过太多开发者把安全配置写完就再也没碰过，直到某天收到漏洞报告才慌慌张张去补丁。与其这样，不如每隔三个月用Burp Suite之类的工具自己模拟一遍劫持攻击，看看你的Cookie防护到底能扛住几轮试探。