cookie欺骗

2019年，欺骗安全研究者Sam Curry在Twitter上发了一条推文，欺骗说他花10美元买了一个“管理员”身份。欺骗具体操作很简单：他在Chrome开发者工具里把某个网站cookie中的欺骗role=user改成了role=admin，刷新页面，欺骗后台管理面板就对他敞开了。欺骗这条推文被转了两万多次，欺骗评论区一半人在笑，欺骗另一半人在检查自己公司的欺骗网站。

cookie欺骗的欺骗本质就这么朴素——服务器太信任客户端了。HTTP是欺骗无状态协议，服务器记不住你是欺骗谁，所以它发给你一张“通行证”，欺骗也就是欺骗cookie，你每次请求都带着它。欺骗问题在于，这张通行证存在你自己的浏览器里，你能看见它，也能改它。如果服务器只看cookie里的内容就决定给你什么权限，那等于把钥匙藏在门垫下面，还贴了张纸条写着“钥匙在此”。

早期电商网站特别喜欢把购物车信息、用户ID甚至价格直接塞进cookie。我见过一个案例：某在线教育平台把课程价格写在cookie里，用户把price=299改成price=0.01，下单成功。这不是什么高深漏洞，就是开发时图省事。后来这种做法少了，但换个马甲又出现了——把Base64编码的JSON塞进cookie，以为编码等于加密。Base64解码不要太容易，浏览器控制台一行atob()就还原了。

更隐蔽的一种是“记住我”功能。很多网站给你一个长期有效的cookie，里面存着用户名或者用户ID的哈希。如果哈希算法弱，比如直接用MD5拼个固定盐值，攻击者拿到自己的cookie就能反推出构造规则，然后伪造别人的。2016年某社交平台就栽在这上面，安全研究员发现它的“记住我”cookie是md5(username+secret)，而secret是硬编码在客户端JS里的。等于把密码本和锁一起给了你。

防御手段其实不复杂，但需要开发者在架构层面想清楚。第一，cookie里不要放敏感信息，放一个随机生成的session ID就够了，真正的权限数据存在服务端。第二，给cookie加上HttpOnly和Secure标记，前者让JavaScript读不到，后者只走HTTPS。第三，签名。就算要在cookie里放数据，也得用服务端密钥做HMAC签名，客户端改了内容签名就对不上。第四，别自己发明加密方案，用成熟的JWT或者服务端session框架。

我自己的习惯是，每次登录一个新网站，先打开开发者工具看一眼cookie。如果看到user_id=123、is_admin=false这种明文键值对，心里就咯噔一下。不是说一定有漏洞，但这种设计思路本身就让人不放心。反过来，如果cookie是一长串毫无规律的字符，或者是个结构规整的JWT，至少说明开发者想过这个问题。

说到底，cookie欺骗能成功，根子上是信任边界没划清。客户端的一切输入都不可信，cookie也不例外。它只是HTTP协议的一个补丁，不是安全机制。把权限判断交给cookie，就像让嫌疑人自己写口供，还不用签字画押。