CC防御会话异常检测识别伪造用户会话请求

CC攻击的会话异常检测之所以难，是因为攻击者早已不再使用固定IP或固定Cookie发起请求，而是通过代理池、秒拨IP、无头浏览器和随机化指纹来模拟真实用户。传统基于IP频率、单会话请求速率的规则，在攻击流量与正常流量混杂时，误杀率和漏判率会同时飙升。真正有效的做法不是继续堆规则，而是把会话请求序列当作一个行为样本，从时序特征、交互逻辑、环境一致性和状态转移四个维度识别伪造会话。

正常用户从打开页面到产生后续请求，存在自然的思考时间和操作间隔。即使是快速点击，人类的手指移动、视觉定位和页面响应之间也会形成几十到几百毫秒的随机延迟。伪造会话请求通常由脚本生成，请求间隔呈现两种极端：要么是精确到毫秒的固定间隔，要么是远低于人类极限的爆发式提交。检测时不要只看平均请求速率，而要分析相邻请求时间差的分布。正常会话的时间差近似对数正态分布，方差较大；脚本会话的时间差分布极窄，或者出现大量完全相同的间隔值。可以计算会话内时间间隔的变异系数，当变异系数低于阈值且请求次数超过一定量时，直接标记为异常。另一个有效特征是“首请求到次请求”的延迟，真实用户首次访问页面后需要时间阅读内容，脚本往往在页面加载完成后立即触发下一个请求，这个延迟通常在100毫秒以内。

伪造会话最大的破绽在于它不关心页面内容，只关心请求是否到达。正常用户在站内的行为有明确的逻辑链条：访问列表页、点击详情页、停留、可能加入购物车或提交表单。脚本生成的会话往往直接请求目标URL，缺少前置页面访问记录，或者跳转路径不符合站内信息架构。在检测时可以维护一个合法的页面跳转关系图，记录Referer与当前请求路径的对应关系。如果某个会话连续多次出现“无Referer直接访问深层页面”或“从A类页面直接跳到C类页面且跳过B类中间页”，就需要提高该会话的风险分。对于表单提交类接口，正常用户会先GET表单页面，再POST提交数据，且GET与POST之间的时间差通常在数秒以上。脚本经常直接POST，或者GET后立即POST，时间差小于1秒。这种交互逻辑校验不需要复杂模型，用简单的状态机就能实现。

攻击者可以伪造User-Agent，可以随机化Canvas指纹，但很难在所有维度上保持一致性。一个会话内的多个请求，其浏览器环境应该是稳定的：相同的User-Agent、相同的Accept头顺序、相同的TLS指纹、相同的屏幕分辨率、相同的时区。如果同一个会话ID下，不同请求的User-Agent在桌面端和移动端之间切换，或者TLS握手特征发生变化，说明这个会话被脚本劫持或伪造。更进一步，可以校验HTTP头字段的排列顺序。真实浏览器的请求头顺序是固定的，而脚本工具生成的请求头顺序往往与浏览器不一致。在服务端记录每个会话首次请求的指纹特征，后续请求逐一比对，不一致即加分。对于使用代理池的攻击，IP会变，但设备指纹和会话ID通常保持不变，因此环境一致性校验比IP信誉更可靠。

把用户在一个会话内的行为抽象为状态序列，正常用户的状态转移有规律可循，而伪造会话的状态转移往往是随机跳变或机械重复。例如电商场景中，正常用户的状态可能是“浏览→搜索→浏览→详情→加购→结算”，脚本可能是“详情→详情→详情→详情”或“搜索→搜索→搜索”。可以基于历史正常流量训练一个马尔可夫链模型，计算当前会话状态转移序列的出现概率。概率低于阈值的会话即为异常。不需要复杂的深度学习，一阶或二阶马尔可夫模型就能识别大部分机械行为。同时可以统计会话内相同请求的重复次数，正常用户很少在短时间内重复请求完全相同的URL，而脚本经常对同一接口进行高频轮询。对于API类接口，可以检测参数组合的多样性，正常用户的参数组合是离散且语义相关的，脚本的参数往往是随机生成或字典遍历，参数值的熵和分布会异常。

固定阈值在流量波动时容易失效。更好的方式是为每个业务接口建立动态基线，统计过去一段时间内该接口的请求速率、会话内请求间隔分布、异常会话占比等指标。当实时流量偏离基线超过一定倍数时，触发会话级审查。滑动窗口建议设置为5到10分钟，基线更新频率为1分钟。对于突发流量，可以结合源IP的熵值变化来判断：正常流量增长时，源IP数量会同步增长且分布均匀；CC攻击流量增长时，源IP数量增长有限但单个IP的会话数和请求数激增。计算源IP的香农熵，熵值突然下降说明流量集中在少数来源，这是攻击的强信号。动态基线配合熵值检测，可以在攻击早期就发现异常，而不是等服务器已经过载才告警。

实际部署时不需要对每个请求做全量分析，那样开销太大。可以在网关层或应用层做一个两级过滤：第一级用Redis或内存缓存维护会话的轻量特征，包括最近N个请求的时间戳、URL、Referer和关键指纹字段，每次请求更新并计算基础特征。第二级对触发基础规则的可疑会话做深度分析，包括状态转移概率、环境一致性校验和历史行为比对。下面是一个简化的会话特征提取示例：

# 会话特征记录结构
session_feature = {
    "sid": "abc123",
    "first_seen": 1710000000,
    "last_seen": 1710000120,
    "request_count": 18,
    "interval_list": [120, 350, 80, 95, 88, 92, 90, 89, 91, 87],
    "url_list": ["/", "/search", "/detail/1", "/detail/1", "/detail/1"],
    "referer_list": ["", "/", "/search", "/detail/1", "/detail/1"],
    "ua_list": ["Mozilla/5.0 ...", "Mozilla/5.0 ..."],
    "tls_fp_list": ["771-4865-4866", "771-4865-4866"]
}

# 计算时间间隔变异系数
import statistics
intervals = session_feature["interval_list"]
cv = statistics.stdev(intervals) / statistics.mean(intervals)
if cv < 0.15 and len(intervals) > 8:
    mark_risk(session_feature["sid"], "interval_cv_low")

# 检测重复URL占比
from collections import Counter
url_counts = Counter(session_feature["url_list"])
repeat_ratio = 1 - len(url_counts) / len(session_feature["url_list"])
if repeat_ratio > 0.6:
    mark_risk(session_feature["sid"], "repeat_url_high")

上述代码只展示了最基础的检测逻辑，实际系统中需要结合业务场景调整阈值，并且对白名单用户和搜索引擎爬虫做排除处理。关键是要让检测逻辑可解释，每次标记风险时都能给出具体原因，方便后续人工复核和规则调优。

任何会话异常检测上线前都必须经过灰度验证。可以先在影子模式下运行，只记录风险标记不实际拦截，观察一周内标记的会话中有多少是真实攻击，多少是误判。误判率超过5%就需要调整阈值或增加白名单逻辑。常见的误判来源包括：移动端弱网环境下的请求重试、企业内网NAT出口的大量用户共享IP、以及某些浏览器插件产生的额外请求。对于这些场景，可以通过增加设备指纹维度、放宽时间间隔阈值、或者对特定User-Agent和请求头特征做白名单来降低误判。灰度验证通过后，再逐步切换到拦截模式，并保留申诉和回退机制。

会话异常检测的核心价值在于它不依赖攻击者的网络层特征，而是从行为层面识别伪造。即使攻击者换了IP、换了设备指纹、用了无头浏览器，只要它的行为模式与真实用户存在统计差异，就能被捕捉到。这套方法配合基础CC防护规则使用，可以显著降低误杀率，同时提高对分布式慢速攻击和模拟真实浏览行为的攻击的识别能力。