CC防护前端埋点收集用户行为用于二次验证评分

CC防护（Challenge Collapsar，即挑战黑洞）是一种专门针对HTTP层DDoS攻击和CC攻击的安全防护策略。传统的CC防护依赖IP频率、请求频率等静态规则来拦截恶意流量，但这种方式容易误伤正常用户，尤其是在高并发场景下。现在业界主流的做法是在前端埋点，收集用户的行为特征数据，将这些数据回传到后端进行二次验证评分，从而精准区分真实用户和机器攻击。简单来说，就是前端通过JavaScript采集用户的鼠标轨迹、点击节奏、页面停留时长、滚动行为等多维度数据，后端根据这些行为数据给每个请求打一个"真人分数"，分数低于阈值的直接拦截或触发验证码，分数高的直接放行。这套机制的核心价值在于：把防护粒度从"IP级"细化到了"行为级"，大幅降低误杀率。

一、为什么传统CC防护需要引入前端埋点

传统CC防护的逻辑非常简单粗暴：同一个IP在单位时间内发起超过N次请求，就判定为攻击。但这个逻辑有三个致命缺陷。第一，NAT网关和共享IP场景下，一个公网IP背后可能是几百个真实用户，一刀切全部拦截等于把正常流量也杀了。第二，现在的攻击工具已经进化到慢速攻击模式，每个IP每秒只发一两个请求，频率规则根本抓不住。第三，高级Bot可以模拟正常用户的请求频率，单靠频率维度已经无法有效识别。

前端埋点的引入，本质上是把"判断用户是不是真人"这个问题，从服务端的流量分析转移到了客户端的行为采集。因为真人和机器在操作浏览器时的行为模式差异是巨大的。真人会有鼠标的无规则移动、会有犹豫停顿、会滚动页面、会在输入框里打字再删掉再打。而Bot程序通常是直接构造HTTP请求，没有这些"人味儿"的行为特征。所以前端埋点收集到的数据，天然就是区分人机的高质量信号。

二、前端埋点具体采集哪些行为数据

要做好二次验证评分，前端埋点需要采集的数据维度必须足够丰富。以下是目前业内公认的核心采集指标：

第一类是鼠标行为数据。包括鼠标移动轨迹的坐标序列、移动速度变化曲线、鼠标点击的时间间隔、点击位置的分布热力图。真人的鼠标轨迹是带有加速度变化的曲线，而Bot的轨迹通常是直线或者完全没有鼠标事件。

第二类是键盘行为数据。包括按键按下和抬起的时间戳、按键间隔、是否有退格删除操作、输入速度的波动情况。真人打字会有停顿、会打错、会修改，Bot要么不输入要么瞬间填完。

第三类是页面交互数据。包括页面滚动的距离和速度、页面可见区域的停留时长、是否有窗口失焦再聚焦的行为、是否触发了页面的hover事件、表单提交前是否有浏览行为。

第四类是环境指纹数据。包括浏览器的User-Agent、屏幕分辨率、时区、语言设置、Canvas指纹、WebGL指纹、AudioContext指纹等。这些数据虽然不是行为数据，但和行为数据结合后可以大幅提升评分准确性。

第五类是时序特征数据。包括页面加载完成到第一次交互的时间、每次请求之间的间隔分布、会话持续时长等。真人的时序特征有明显的随机性和波动性，Bot则呈现机械的规律性。

三、前端埋点的技术实现方案

前端埋点的实现并不复杂，但需要注意性能和隐蔽性两个关键点。性能方面，埋点代码不能影响正常页面的加载和交互体验；隐蔽性方面，埋点逻辑不能被Bot轻易识别和绕过。下面给出一个基础的实现示例：

// 基础行为采集模块
class BehaviorCollector {
  constructor() {
    this.events = [];
    this.startTime = Date.now();
    this.mouseTrail = [];
    this.init();
  }

  init() {
    // 鼠标移动轨迹采集
    document.addEventListener('mousemove', (e) => {
      this.mouseTrail.push({
        x: e.clientX,
        y: e.clientY,
        t: Date.now() - this.startTime
      });
      // 限制存储数量，避免内存溢出
      if (this.mouseTrail.length > 200) {
        this.mouseTrail.shift();
      }
    });

    // 鼠标点击采集
    document.addEventListener('click', (e) => {
      this.events.push({
        type: 'click',
        x: e.clientX,
        y: e.clientY,
        t: Date.now() - this.startTime
      });
    });

    // 键盘行为采集
    document.addEventListener('keydown', (e) => {
      this.events.push({
        type: 'keydown',
        key: e.key,
        t: Date.now() - this.startTime
      });
    });

    // 页面滚动采集
    window.addEventListener('scroll', () => {
      this.events.push({
        type: 'scroll',
        scrollY: window.scrollY,
        t: Date.now() - this.startTime
      });
    });

    // 窗口失焦采集（检测是否为后台脚本）
    window.addEventListener('blur', () => {
      this.events.push({
        type: 'blur',
        t: Date.now() - this.startTime
      });
    });
  }

  // 汇总并上报数据
  report() {
    const payload = {
      mouseTrail: this.mouseTrail,
      events: this.events,
      duration: Date.now() - this.startTime,
      fingerprint: this.getFingerprint()
    };

    // 使用navigator.sendBeacon确保数据可靠上报
    navigator.sendBeacon('/api/behavior/report', 
      JSON.stringify(payload));
  }

  getFingerprint() {
    return {
      ua: navigator.userAgent,
      screen: `${screen.width}x${screen.height}`,
      timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
      language: navigator.language
    };
  }
}

上面这段代码展示了一个最小化的行为采集器。在生产环境中，还需要做几件事：一是对数据进行压缩和编码，减少传输体积；二是加入随机延迟和数据混淆，防止Bot分析采集逻辑后伪造数据；三是在页面关键交互节点（如登录、提交表单）触发上报，而不是持续上报，减少服务器压力。

四、后端二次验证评分模型的构建

前端采集到的数据回传到后端后，需要通过评分模型来判定这个请求是否来自真实用户。评分模型的构建通常有两种路径：规则引擎和机器学习模型。

规则引擎方式比较直接，就是给每个行为维度设定权重和阈值。比如鼠标轨迹的曲率低于某个值扣分，没有滚动行为扣分，请求间隔过于均匀扣分，没有键盘事件扣分。所有维度的得分加权求和，得到一个总分。这种方式的优点是可解释性强、部署简单，缺点是规则需要人工持续调优，面对新型Bot的适应性较差。

机器学习方式则是用历史的真实用户数据和已知攻击数据训练一个分类模型。常用的算法包括随机森林、XGBoost、LightGBM等。输入特征就是前端采集的各种行为指标，输出是"真人概率"。这种方式的优点是自适应能力强，能发现人工规则难以覆盖的攻击模式，缺点是需要足够的标注数据，模型训练和更新有一定成本。

实际生产环境中，建议采用"规则+模型"的混合策略。规则引擎做第一层快速过滤，把明显异常的请求直接拦截；机器学习模型做第二层精细判断，对处于灰色地带的请求给出概率评分。这样既保证了响应速度，又兼顾了准确性。

五、评分结果如何与CC防护策略联动

二次验证评分不是孤立存在的，它必须和现有的CC防护体系深度整合。具体的联动策略通常分为三个等级：

绿色通道（高分段，比如80分以上）：直接放行，不做任何额外验证，用户体验完全无感。这是我们追求的目标，让绝大多数真实用户都走这条路。

黄色通道（中等分段，比如50-80分）：触发轻量级验证，比如滑块验证码、短信验证码、或者要求用户完成一个简单的交互任务。这种方式对用户体验有轻微影响，但能有效拦截大部分中等复杂度的Bot。

红色通道（低分段，比如50分以下）：直接拦截请求，返回403或429状态码，同时记录该请求的特征用于后续分析和模型迭代。

还有一个重要的点是动态调整。评分阈值不能一成不变，需要根据当前的攻击态势动态调整。在攻击高峰期，可以适当降低绿色通道的门槛，优先保证正常用户的访问；在平时，可以提高门槛，收紧防护。

六、前端埋点方案需要注意的关键问题

第一是性能影响。行为采集代码如果写得不好，会导致页面卡顿，尤其是在移动端。解决方案是使用requestIdleCallback或者Web Worker在空闲时处理数据，避免阻塞主线程。

第二是数据安全和隐私合规。采集用户行为数据涉及个人隐私，必须符合相关法律法规的要求。需要在用户协议中明确告知数据采集的目的和范围，并且对采集的数据进行脱敏处理，不存储可直接关联到个人身份的信息。

第三是反绕过能力。高级攻击者会分析前端埋点代码，然后用Puppeteer、Playwright等工具模拟真实的鼠标和键盘行为来绕过检测。应对策略包括：采集数据中加入不可预测的随机因子、在服务端对上报数据做合法性校验（比如检查数据的时间戳是否合理、轨迹是否符合物理规律）、定期更新采集逻辑。

第四是数据传输的可靠性。前端上报的数据可能因为网络问题丢失，不能因为一次上报失败就判定用户为攻击。需要有重试机制和容错逻辑，同时在服务端对数据完整性做校验。

七、这套方案的实际效果和行业趋势

从实际部署效果来看，引入前端埋点二次验证后，CC防护的误杀率通常可以降低60%-80%。尤其是在电商大促、票务抢购等高并发场景下，这个提升非常显著。同时，因为精准识别了攻击流量，防护策略可以更加激进，整体的防护能力反而提升了。

从行业趋势来看，行为验证正在成为CC防护的标配能力。未来的方向是把前端埋点、后端评分、威胁情报、设备指纹等多个维度的数据融合在一起，构建一个实时的、自适应的智能防护体系。同时，随着浏览器隐私政策的收紧（比如限制第三方Cookie、限制指纹采集），如何在合规前提下获取足够的行为数据，将是下一个需要攻克的难题。

总结来说，CC防护前端埋点收集用户行为用于二次验证评分，是一种从"流量层防护"升级到"行为层防护"的技术演进。它的核心思路是用前端采集的丰富行为数据，在后端构建精准的人机识别模型，从而实现对CC攻击的精细化拦截。这套方案不是万能的，但在当前的技术条件下，它是平衡防护效果和用户体验的最优解之一。