CC防护中请求合法性评分结合业务上下文动态调整阈值

CC（Challenge Collapsar）攻击的可怕之处不在于流量有多大，而在于它长得太像正常请求了。传统的频率限制和固定阈值策略之所以频频失效，是因为它们把“请求合法性”当成一个非黑即白的判断题，而现实中，一个携带完整Cookie、走了正确跳转流程的恶意请求，和一个因为网络抖动重试了两次的正常用户请求，在特征层面几乎无法区分。解决这个问题的关键，在于把“合法性”从一个静态标签变成一个动态分数，并且让这个分数的及格线随着业务上下文实时浮动。

要动态调整阈值，首先得有一套能细粒度量化请求可信度的评分体系。这个评分不是简单的“通过”或“拦截”，而是一个从0到100的连续分值，0代表确定无疑的攻击流量，100代表毫无争议的真实用户。评分可以从以下几个维度综合计算：

网络层行为特征：TCP握手行为里藏着大量信息。比如SYN包的重传次数、TCP窗口大小的协商模式、TLS指纹（JA3/JA4指纹）是否与主流浏览器匹配。一个真实的Chrome浏览器发出的TLS握手特征，和一个用Python脚本模拟的请求，在指纹层面有显著差异。这部分可以给出一个基础分，例如TLS指纹匹配主流浏览器得30分，匹配已知恶意工具链得0分，未知指纹得15分。

HTTP协议合规性：请求头顺序是否符合对应浏览器的实现规范、Accept-Language和Accept-Encoding等头部是否存在且合理、User-Agent声称的浏览器版本是否与其支持的TLS版本和加密套件一致。很多攻击工具会伪造User-Agent但忘记调整其他头部，这种不一致性可以直接扣分。

客户端环境验证：通过注入JavaScript挑战来检测执行环境。检测项包括：JavaScript引擎是否存在、能否正常执行非对称加密运算、DOM环境是否完整、屏幕分辨率和色深等设备信息是否合理。这部分验证能有效区分真实浏览器和简单脚本，给出一个较高权重的评分项。

行为序列合理性：一个正常用户访问网站，其行为序列是有逻辑的。先请求HTML页面，然后加载CSS和JS资源，接着可能发送XHR请求获取数据，最后提交表单。如果某个IP直接对敏感接口发起POST请求，前面没有任何页面浏览记录，这个请求的可信度就极低。行为序列可以通过会话追踪来建模，为每个会话维护一个状态机，根据当前请求在状态机中的位置给出相应分数。

业务上下文是让阈值“动”起来的关键变量。不同业务场景下，对“合法”的定义完全不同。一个电商网站在大促秒杀场景下，用户短时间内发起大量请求是正常行为；但同样的请求模式出现在一个政府网站的登录接口上，就极可能是撞库攻击。业务上下文可以从以下角度量化并映射为阈值调整因子：

接口敏感度分级：将业务系统的所有API按照风险等级划分为多个级别。第一级是公开只读接口，如文章列表、商品详情，这类接口的合法性阈值可以设得较低，比如40分即可放行。第二级是需要登录但非敏感操作的接口，如加入购物车、收藏文章，阈值提高到60分。第三级是涉及用户资产或敏感信息的接口，如提交订单、修改密码、查看个人身份信息，阈值需要提高到80分。第四级是资金交易或权限变更接口，如支付确认、管理员操作，阈值可以设置到90分以上，甚至要求满分才放行。

用户身份权重：已登录用户和未登录用户天然具有不同的信任基础。一个已经通过手机号验证、有半年以上正常购买记录的老用户，其请求的合法性评分可以在基础分上乘以一个信任系数，比如1.2倍。而一个刚注册三分钟、尚未绑定任何信息的账号，其信任系数可能是0.8。这个系数直接作用在阈值上，相当于为高价值用户降低了门槛，为低信任度用户抬高了门槛。

时段与运营节奏：凌晨三点和晚上八点的正常流量模型完全不同。凌晨时段，整体流量低，攻击者往往选择此时发动攻击，因为异常流量更容易被淹没在低基数中。此时可以全局上调阈值，让系统更加敏感。而在大促活动期间，用户行为本身就会偏离日常模式，此时需要适当下调阈值，避免误杀真实购买需求。这些调整可以通过预设的运营日历自动触发，也可以基于实时流量预测动态计算。

业务指标异常信号：当关键业务指标出现异常波动时，阈值应该自动收紧。例如注册成功率突然从85%飙升到99%，这可能意味着注册接口正在被自动化脚本批量调用；支付失败率异常升高，可能是有人在测试盗用卡片。将这些业务指标通过消息队列实时输入到CC防护引擎中，作为阈值调整的触发条件，可以实现业务感知的防护策略。

将上述理念落地，需要一个能够实时计算评分、实时调整阈值的工程架构。核心组件包括评分引擎、上下文采集器、阈值决策器和执行器四个部分。

评分引擎负责对每个请求进行多维度打分。它需要接入TLS指纹库、User-Agent解析库、JavaScript挑战验证服务，以及行为序列分析模块。评分引擎的输出是一个带有多维度明细的分数对象，不仅包含总分，还包含每个维度的子分数，供后续阈值决策器使用。

上下文采集器是一个独立的数据管道，它从业务数据库中拉取接口分级配置、用户画像数据、运营日历信息，从监控系统中获取实时业务指标，从流量分析模块获取当前时段的流量基线数据。这些数据经过清洗和标准化后，写入一个高性能的内存键值存储中，供阈值决策器实时读取。

阈值决策器是整个系统的核心。它维护一个阈值计算公式，输入是上下文采集器提供的各项上下文变量，输出是当前时刻、当前接口、当前用户类型下的具体阈值。一个简化的公式示例如下：

threshold = base_threshold[api_level] * time_factor * user_trust_coefficient * anomaly_penalty

其中：
base_threshold[api_level] 根据接口敏感度取基础值，如 [40, 60, 80, 95]
time_factor 根据时段和运营节奏取值，范围 0.8-1.2
user_trust_coefficient 根据用户画像取值，范围 0.7-1.3
anomaly_penalty 当业务指标异常时取值 1.0-1.5，正常时为 1.0

执行器接收评分引擎给出的请求分数和阈值决策器给出的动态阈值，进行比较后做出放行、拦截或二次验证的决定。对于分数接近阈值的“灰色地带”请求，执行器可以返回一个JavaScript挑战或验证码，给真实用户一个自证清白的机会，同时有效拦截自动化攻击。

攻击手法在不断进化，评分模型如果一成不变，很快就会被绕过。需要建立一套闭环的反馈机制，让模型能够持续学习。具体做法包括：

误杀反馈收集：当用户被拦截后，如果通过客服渠道申诉并成功验证身份，这个案例应该被记录下来。分析被误杀的请求在各个评分维度上的表现，找出导致误判的关键维度，调整其权重或评分规则。

漏过流量分析：通过后端业务日志分析，找出那些成功通过防护但仍然产生了异常行为的请求。例如一个请求通过了所有检查，但随后在业务层面进行了欺诈交易。回溯这个请求的评分明细，找出评分模型未能识别出的风险特征，补充新的检测维度。

攻击样本标注：安全团队在日常运营中发现的攻击样本，应该被系统性地标注并纳入训练数据集。定期基于积累的标注数据重新评估评分模型的效果，通过A/B测试验证新规则的有效性后再全量上线。

这种自适应演进机制，使得整个防护系统不再是一个静态的规则集合，而是一个能够随着业务发展和攻击手法变化而持续优化的智能体。

单个节点的评分和阈值调整能力终究有限。当业务部署在多机房、多云环境时，一个攻击源可能在某个节点被拦截后，迅速切换到另一个节点继续攻击。因此，评分结果和阈值决策需要在全局层面共享和协同。

可以在各边缘节点之上构建一个中心化的决策协同服务，各节点将请求的评分明细和上下文信息实时上报，由中心服务进行全局聚合分析。当一个IP在节点A被判定为高风险后，这个判定结果需要在毫秒级同步到所有其他节点，使得攻击者在全局范围内都无法得逞。

更进一步，全局协同层还可以实现跨业务的威胁情报共享。同一个攻击源可能同时攻击公司的多个业务线，通过全局视角可以更快地识别和封堵。这种协同能力对于大型组织来说尤其重要，能够将单点的防护能力放大为整个集团的防护网络。

将请求合法性评分与业务上下文动态结合的CC防护策略，本质上是在安全性和可用性之间寻找一个动态平衡点。它承认了一个事实：绝对的安全是不存在的，过度防护必然伤害用户体验。通过精细化的评分体系和灵活的阈值调整机制，可以在保障业务正常运行的前提下，最大化地压制攻击空间。这套体系的价值不在于某个单一技术点的突破，而在于将安全能力真正融入了业务的脉搏之中。