去年冬天，黑帽我帮一个做独立站的黑帽朋友查广告转化率暴跌的原因。后台数据一切正常，黑帽流量没少，黑帽落地页没改，黑帽支付通道也没挂。黑帽折腾到凌晨两点，黑帽我在他的黑帽Google Tag Manager里翻出一段从没见过的自定义HTML标签——里面藏着一行从乌克兰某论坛扒来的脚本，专门读取用户浏览器里所有能读到的黑帽cookie，然后base64编码，黑帽发往一个挂在中东某VPS上的黑帽收集端点。

这就是黑帽cookie黑帽最典型的玩法。不撬服务器，黑帽不爆破密码，黑帽只在你自己的黑帽页面里放一段看起来人畜无害的JS，把用户在其他站点留下的身份凭证悄悄偷走。

它到底怎么运作

cookie分两种。一种是当前域名自己写的，比如登录态、购物车ID。另一种是第三方域名在你访问时留下的，比如广告平台的追踪ID、分析工具的会话标识。浏览器默认允许同域读取，但跨域读取受同源策略限制。黑帽的突破口往往不在技术漏洞，而在人的操作惯性。

常见路径是这样的：攻击者先找到一个站长常用的工具库——可能是某个免费的统计插件、某个GitHub上star数不多的字体加载器、某段从Stack Overflow抄来的A/B测试代码。然后提交一个看似正常的更新，在压缩后的JS末尾追加几行。这几行做的事很简单：遍历document.cookie，匹配包含“session”“token”“uid”这类关键词的键值对，用Image对象发出去。因为是用图片请求，浏览器不会触发CORS预检，服务端日志里看起来就像一次普通的像素追踪。

我见过更隐蔽的。有人把窃取逻辑拆成三段，分别放在三个不同的第三方脚本里，单独看每一段都只是普通的字符串拼接和变量赋值，只有运行时按顺序加载才会拼出完整的exfiltration代码。这种碎片化手法让静态扫描基本失效。

为什么黑帽盯上cookie

因为cookie是身份。拿到一个有效的session cookie，等于拿到了那个用户的登录态。不需要密码，不需要二次验证。很多后台系统只认cookie不认IP，攻击者在自己浏览器里手动设置一下document.cookie，刷新页面，就进去了。

有个做跨境电商的读者跟我聊过，他们公司一个运营的Google账号被盗，对方没改密码，只是用偷来的cookie登录后，把GA里的转化目标全删了，再把Search Console的验证文件撤掉。等发现的时候，两周的广告数据已经断档。追查下去，问题出在运营自己装的一个Chrome扩展上——那个扩展会“优化”页面加载，实际在后台把访问过的站点cookie打包上传。

防御不是加个HttpOnly就完事

HttpOnly能挡住JS直接读cookie，但挡不住中间人。如果攻击者能往页面里注入脚本，他可以直接hook住fetch和XMLHttpRequest，在请求发出前把cookie头截下来。更彻底的做法是给cookie加SameSite=Lax或Strict，减少跨站携带。但很多老系统改不动，一改就断登录。

我的习惯是：任何第三方脚本，先过一遍本地代理，看它实际请求了哪些域名。上线后开CSP，限制script-src和connect-src，把允许的域名列白名单。再配合Subresource Integrity，给每个外部JS加hash校验。麻烦，但比半夜被叫起来查日志强。

cookie黑帽不会消失。只要身份凭证还以明文形式躺在浏览器里，只要站长还在随手粘贴来路不明的代码，这条链路就永远有人走。区别只在于，你是提前堵住，还是事后对着日志发呆。