摘要：# 别以为加个Cookie就安全了：聊聊CC防护里那点“小心思” 前两天帮一个做电商的朋友看后台，他指着监控图上一片飘红的请求数直挠头：“我明明上了防CC啊，就那个基于Cookie验证的，怎么感觉没啥用呢？” 我登录后台看了一眼规则配置，好嘛，典型的“…

别以为加个Cookie就安全了：聊聊CC防护里那点“小心思”

前两天帮一个做电商的朋友看后台，他指着监控图上一片飘红的请求数直挠头：“我明明上了防CC啊，就那个基于Cookie验证的，怎么感觉没啥用呢？”

我登录后台看了一眼规则配置，好嘛，典型的“教科书式部署”——开了会话保持，勾了动态校验，然后……就没了。流量一上来，CPU该跑满还是跑满。

我问他：“你这Cookie，是让人‘看一眼’就过，还是真得‘掏身份证’核对？”

他愣了下，没太明白。

说白了，现在很多号称“基于Cookie验证”的防CC机制，其实只做了一半。它们确实能给访客发个“门卡”（Cookie），但检查的时候，可能就看一眼门卡颜色对不对，根本不管里面的人是不是当初领卡的那位。这种防护，对付初级脚本还行，遇到会模仿、会伪装的“高级爬虫”，基本就是形同虚设。

今天咱就掰开揉碎了聊聊，一个真正能扛事的Cookie防CC机制，到底该在哪些细节上较真。

会话保持：不是发了票就完事

会话保持，听着挺技术，其实原理跟去游乐场差不多。

你买票进门（首次访问），工作人员给你手背上盖个荧光章（服务器下发Cookie）。之后你在园内玩任何项目（访问网站其他页面），工作人员只需在暗处拿灯一照（验证Cookie存在且有效），就放行了。这避免了每次玩项目都要重新查票的麻烦，体验很流畅。

但问题就出在这个“章”上。

很多方案的“章”太容易仿造了。 它可能就是个简单的、有一定规律的字符串，比如sessionid=123456。攻击者只要批量采集一批这样的有效Cookie，就能让他的肉鸡（代理IP）轮流拿着这些“门票”入场，轻松绕过“首次访问”的限制。你的会话保持，成了给人家的攻击做持久化。

那怎么办？得在“章”本身上下功夫。

• 给章加隐形防伪（加密与混淆）： 别再用简单递增的数字了。这个Cookie值应该是一串无规律的、经过加密的密文。里面可以埋入时间戳、客户端指纹（如浏览器细微特征哈希值）、甚至一个只有服务器才知道的随机种子。这样一来，即使攻击者截获了一个Cookie，他也无法批量伪造出其他有效的“章”。
• 给章设定有效期（短时会话）： 这个荧光章，不能是永久的。应该设置一个较短的有效期，比如5-10分钟。超时后，章自动失效，用户需要重新“买票”（通过一次轻量级验证，比如计算一个简单的JS挑战）。这大大增加了攻击者维持攻击成本——他得不停地去获取新的、有效的Cookie。
• 一个章只认一个人（绑定客户端特征）： 这是关键！下发Cookie时，可以悄悄地、在不侵犯隐私的前提下，记录客户端的一些轻度指纹信息（比如User-Agent的哈希、TCP窗口尺寸等），并加密后关联到Cookie里。下次验证时，不光看“章”，还要暗地里核对一下“领章的人”和现在“用章的人”特征是否高度吻合。如果突然这个章从Windows Chrome跳到了Linux Firefox上用，那就可以直接拦截或要求二次验证。

说白了，会话保持不能是“一劳永逸”的通行证，它得是个“限时、限人、防伪”的临时凭证。

动态校验：别把考场答案公开贴墙上

动态校验，是Cookie防CC里最能体现“攻防对抗”智慧的地方。它的核心思想是：服务器不断出题（动态令牌），客户端必须实时解题，才能证明自己是个“活人”浏览器，而不是死板的脚本。

但很多方案的落地，简直让人哭笑不得。

最常见的一种“伪动态”，是在Cookie里藏一个固定算法生成的Token。比如，Token = MD5(时间戳小时部分 + 固定密钥)。攻击者只要摸清这个算法，就能在自己的脚本里完美复现，要多少Token有多少。

真正的动态校验，应该是这样的：

1. 每次出的题都不一样（随机性）： 服务器在响应中，通过一段JavaScript，动态生成一个一次性的、随机的挑战值（比如一个随机数），并同时计算出该挑战值对应的正确答案（比如挑战值 + 1），加密后种在Cookie或下一个请求的Header里。
2. 客户端必须执行代码才能解题（JS依赖）： 浏览器会自动执行JS，完成计算（得到挑战值 + 1），并在下一个请求中携带这个结果。而大多数简单的爬虫脚本、CC工具，是没有完整JS引擎的，它们解析不了这段JS，自然算不出答案。
3. 答案即用即废（一次性）： 服务器收到客户端回传的答案后，与自己之前计算的答案核对。无论对错，这个挑战值立即作废。 同一个答案提交第二次，直接拒绝。这就防止了攻击者录制一次通信过程然后无限重放。

这里有个我亲眼见过的翻车案例：某平台为了追求“零延迟”，把动态校验的JS逻辑和答案验证逻辑都放在了CDN边缘节点。想法是好的，但边缘节点的计算资源有限。攻击者发现了这一点，就用海量IP瞬间请求，每个请求都触发边缘节点执行JS计算和验证，直接把边缘节点的CPU打满，导致正常用户的JS也执行不了，整个校验系统瘫痪。

所以，真正的动态校验，计算密集型的工作（如生成复杂挑战、验证答案）一定要回源站或者有充足计算资源的专用防护节点去做，边缘节点只负责转发和简单的过滤。

组合拳：让防护有点“人味儿”

单独靠会话保持或动态校验，都有短板。但把它们和一些有“人味儿”的策略结合起来，效果就好多了。

• 动静结合： 对于网站首页、商品列表页等静态资源，可以采用宽松的会话保持，提升体验。而对于登录、提交订单、发表评论等动态接口，必须叠加严格的动态校验，甚至滑块验证。
• 速率画像： 别光盯着一个IP的请求频率。可以给每个“会话”（Cookie）也建立一个行为画像。一个正常的用户会话，其访问路径是有逻辑的（首页->列表页->详情页），请求间隔是随机的。如果一个会话在短时间内，以固定毫秒级的间隔，疯狂请求同一个API，那即使它每次Cookie都有效，也明显是机器行为，该封就封。
• 敢于“误杀”： 在CC攻击的峰值期，策略可以临时调至“宁可错杀，不可放过”的级别。比如，将动态校验的频率提高，甚至对部分疑似流量直接返回验证码。这可能会误伤一些使用特殊工具的正常用户（比如SEO蜘蛛、价格监控工具），但保障核心业务不崩盘永远是第一位的。等攻击过去，再放松策略。这点很多运维同学不敢做，怕被投诉，其实关键时刻的果断比周全更重要。

写在最后

基于Cookie的防CC，从来不是一个“开关”，而是一套需要精心调校的“策略组合”。

它的核心，不在于用了多高深的算法，而在于你是否在每一个环节，都比攻击者想多一步：你的Cookie是否足够不可预测？你的动态挑战是否真正依赖浏览器环境？你的验证逻辑是否扛得住资源消耗战？

下次你再检查自己的防CC配置时，别只看功能有没有打开。不妨把自己想象成一个攻击者，试试看：我能不能低成本地批量获取有效Cookie？我能不能在不执行JS的情况下通过验证？我的攻击流量看起来是不是太“规律”了？

多问自己几个这样的问题，你配置出来的规则，离“真有用”就更近了一步。

好了，关于Cookie和CC那点事，今天就聊到这。防护这事儿，永远是在博弈中升级。你的站点，最近有遇到什么有意思的攻击吗？欢迎聊聊。