利用JS跳转验证拦截简单CC攻击脚本

CC攻击的核心痛点在于，它不像洪水攻击那样靠超大流量取胜，而是通过大量看似正常的请求，耗尽服务器处理动态页面的资源。攻击者往往利用代理IP池，每个IP的请求频率并不高，传统的基于IP频率的限流策略很容易误伤正常用户，或者被轻松绕过。这时候，在攻击请求到达真实服务器之前，插入一道几乎不消耗资源的计算型挑战，就成了性价比极高的防御手段。利用JS跳转验证，本质上就是在HTTP响应和真实页面之间，构建一道需要客户端执行JavaScript才能通过的闸门。

这种防御脚本的原理并不复杂。当请求到达服务器时，我们不直接返回页面内容，而是返回一个极简的HTML页面，里面只包含一段JavaScript代码。这段代码负责完成一个轻量级的计算任务，比如设置一个Cookie、解析一段加密参数或者直接执行一次页面跳转。真正的浏览器在收到响应后，会解析并执行这段JS，然后带着计算结果或Cookie重新请求目标页面。而绝大多数CC攻击脚本、底层发包工具，只具备基础的HTTP请求能力，没有JS解析引擎，无法完成这个跳转动作，攻击链路就此中断。

这是最轻量级的实现，适合对用户体验要求极高、且攻击手法相对简单的场景。服务器端在收到请求后，先检查请求中是否携带了特定的验证Cookie。如果没有，就返回一个设置Cookie并自动刷新的页面。这个Cookie可以是一个简单的Token，服务端验证其有效性即可。

<html>
<head>
<meta charset="utf-8">
<title>请稍候...</title>
</head>
<body>
<script>
    // 设置Cookie，有效期可根据需要调整
    document.cookie = "cc_defense=valid_token; path=/; max-age=3600";
    // 刷新当前页面，浏览器会自动带上刚设置的Cookie
    window.location.reload();
</script>
</body>
</html>

这段代码的逻辑非常直白：没有正确Cookie的请求一律得到一个空白页，这个页面通过JS写入Cookie并强制刷新。攻击工具通常不会处理Set-Cookie指令，更不会执行reload，因此无法穿透。不过，这种方式的缺点也很明显：验证逻辑完全依赖一个固定的Cookie值，一旦攻击者分析出这个值并写入发包脚本，防御就会失效。

为了对抗能解析简单JS的高级攻击脚本，我们需要引入动态参数。服务端生成一个随机字符串，嵌入到JS代码中，客户端在执行跳转时必须携带这个加密参数。服务端在第二次收到请求时，解密并校验参数的时间有效性和合法性。这种方式大大增加了攻击者模拟的成本。

<html>
<head>
<meta charset="utf-8">
<title>安全验证中...</title>
</head>
<body>
<script>
    // 直接跳转到带token的地址
    window.location.href = "";
</script>
</body>
</html>

这个方案的精妙之处在于，它把验证信息从Cookie转移到了URL参数中，并且这个参数是动态生成的，包含时间戳和签名。攻击者即便捕获了一次请求的完整URL，这个链接也会在很短时间内失效。对于CC攻击中常见的大规模重放请求，这种动态校验是致命的打击。

上述两种方案都会导致页面出现一次明显的“闪烁”或白屏，用户体验不够完美。如果我们希望验证过程对用户完全透明，可以采用异步验证的思路，但纯JS跳转方案无法做到完全无感，因为它必须中断当前请求。一个折中的优化方案是，在跳转页面加入简单的加载动画，或者更进一步，要求客户端完成一个极小的计算任务（Proof of Work）。

服务端下发一个随机字符串和一个难度值，要求客户端在JS中找到一个数字，使得这个数字与随机字符串拼接后的哈希值前几位为零。这个计算过程在浏览器中耗时通常只有几十毫秒，但对攻击脚本来说，要并发完成大量这样的计算，资源消耗会急剧上升。

<script>
    // 服务端下发的挑战参数
    var challenge = "";
    var difficulty = 4; // 要求哈希值前4位为0
    var nonce = 0;
    var hash = "";
    
    // 寻找满足条件的nonce
    while (true) {
        hash = md5(challenge + nonce);
        if (hash.substring(0, difficulty) === "0000") {
            break;
        }
        nonce++;
    }
    
    // 将找到的nonce和结果提交给服务端验证，或者直接拼接到跳转URL中
    window.location.href = "/validate?nonce=" + nonce + "&challenge=" + challenge;
</script>

这种工作量证明机制，将防御成本转嫁给了攻击者。正常用户的一次页面访问，浏览器在后台瞬间就能完成计算，几乎感知不到延迟。而攻击者想要维持高并发请求，就必须消耗大量CPU资源去计算哈希，这能有效拖垮攻击方的资源。

在实际生产环境中，我们通常不会在应用服务器上直接运行这段逻辑，因为这仍然会消耗一部分动态资源。更优的做法是，将JS跳转验证部署在反向代理层或CDN的边缘节点上。比如，在Nginx中使用Lua脚本或者直接通过OpenResty来实现。当请求到达边缘节点时，就完成Cookie或Token的校验。不合规的请求直接由边缘节点返回JS挑战页面，根本不会回源到后端服务器。这样，即使面临百万级的CC请求，压力也全部由高性能的边缘节点承担，源站服务器安然无恙。

单纯的JS跳转虽然有效，但可能会对搜索引擎爬虫造成影响。因此，我们需要在脚本中加入白名单机制。通过分析User-Agent，对已知的搜索引擎爬虫（如Baiduspider）直接放行，避免影响SEO收录。更进一步，我们可以将JS跳转与请求频率、请求路径特征结合起来。比如，只有当某个IP在短时间内连续请求动态页面，且没有携带合法Cookie时，才触发JS验证。对于第一次访问的普通用户，也可以直接进入JS挑战，但将挑战页面的等待时间设置为零，做到无感过渡。

必须清醒地认识到，没有一劳永逸的防御手段。当JS跳转验证普及后，攻击者也开始使用无头浏览器（如Puppeteer、Playwright）来发动攻击。这些工具能够完整模拟浏览器环境，执行JavaScript。针对这种情况，JS挑战脚本需要进一步升级，比如检测浏览器特有的对象（如navigator.webdriver）、检测Chrome无头模式下的特有属性，或者要求客户端进行Canvas指纹计算。一旦检测到无头浏览器特征，可以故意返回虚假内容或直接阻断连接。这是一场持续的军备竞赛，防御脚本需要定期更新检测指纹和加密算法，才能保持防御的有效性。

利用JS跳转来拦截简单CC攻击，本质上是利用协议层面的不对等优势，在攻击者没有完整浏览器环境的情况下，设置一道必须通过的计算门槛。从简单的Cookie设置，到动态Token校验，再到工作量证明和无头浏览器检测，这套防御体系可以逐步递进。对于绝大多数依靠脚本和代理池的低成本CC攻击，一套设计良好的JS跳转验证脚本，就能在服务器资源几乎零消耗的情况下，将海量攻击请求拒之门外。