网站运营的移动端API的防重放随机数缓存

移动端API的防重放攻击，核心在于每个请求必须携带一个唯一且时效性强的随机数（nonce），服务器通过缓存验证这个随机数是否被重复使用。具体来说，当客户端发起请求时，需要生成一个随机字符串，并连同时间戳和请求数据一起发送。服务器端会检查该随机数是否在缓存中存在，如果存在则判定为重放攻击并拒绝请求；如果不存在，则将其存入缓存，并设置一个合理的过期时间（通常略长于请求的最大时间漂移）。同时，服务器会验证时间戳的新鲜度，丢弃那些过于陈旧的请求，从而构成“随机数+时间戳+缓存”的三重防护机制。

一、为什么移动端API尤其需要防重放机制？

移动应用与Web应用的环境有本质不同。首先，移动端的网络环境更复杂，可能在Wi-Fi、4G/5G之间频繁切换，请求更容易被拦截和捕获。其次，APP一旦发布，其通信逻辑相对固定，攻击者有充足的时间进行静态分析和动态抓包。常见的重放攻击场景包括：重复提交订单消耗用户余额、重复调用领取优惠券接口、恶意刷取积分或内容。如果没有有效的防重放措施，攻击者只需简单地复制一次成功的请求数据，就能在任意时间、任意地点重复执行该操作，给业务安全带来巨大风险。因此，防重放不是可选项，而是移动端API设计的必选项。

二、防重放随机数的核心设计要点

一个健壮的防重放随机数机制，需要精心设计以下几个关键点：

1. 随机数的生成：必须使用密码学安全的随机数生成器（CSPRNG），确保其不可预测性。在Java中可以使用"java.security.SecureRandom"，在Node.js中可以使用"crypto.randomBytes"。切勿使用时间戳或简单递增数字，这些都极易被猜测。

2. 随机数的长度：建议长度不低于16字节（128位），以提供足够的熵值，防止碰撞和暴力枚举。

3. 随机数的传递：通常放在HTTP请求头（如"X-API-Nonce"）中，与业务参数分离，便于中间件统一处理。

4. 时间戳的协同：客户端需要在请求中携带当前时间戳（如"X-API-Timestamp"）。服务器端会验证接收时间与时间戳的差值是否在允许的窗口期内（例如±5分钟）。这能自动清理掉过期的请求，减轻缓存压力。

5. 签名的绑定：为防止随机数和时间戳在传输中被篡改，它们必须参与整个请求的签名计算。签名密钥应为每个客户端独有（如App Key Secret）。这样，任何对随机数或时间戳的修改都会导致签名验证失败。

三、服务器端缓存的选择与实现策略

缓存是防重放验证的“记忆中枢”。其核心任务是高效地判断“此随机数是否已见过”。选择哪种缓存技术，取决于系统的规模和架构：

1. 单机内存缓存（如Caffeine、Guava Cache）：适用于初创项目或单点部署。实现简单，性能极高。但无法在集群环境下共享状态，导致攻击者可能向不同服务器节点重放请求而绕过检查。

2. 分布式缓存（如Redis、Memcached）：这是生产环境的推荐选择。它能提供全局一致的随机数校验。将随机数作为Key，验证成功后存入，并设置一个略大于时间戳窗口的TTL（例如5分钟+10秒）。Redis的单线程特性和高性能非常适合此场景。

下面是一个基于Spring Boot和Redis的简易防重放校验过滤器示例：

@Component
public class ReplayAttackFilter extends OncePerRequestFilter {

    @Autowired
    private RedisTemplateredisTemplate;

    private static final String NONCE_PREFIX = "nonce:";
    private static final long TIMESTAMP_WINDOW = 5 * 60 * 1000; // 5分钟

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {

        String nonce = request.getHeader("X-API-Nonce");
        String timestampStr = request.getHeader("X-API-Timestamp");
        String signature = request.getHeader("X-API-Sign");

        // 1. 基础校验
        if (StringUtils.isEmpty(nonce) || StringUtils.isEmpty(timestampStr) || StringUtils.isEmpty(signature)) {
            sendError(response, "Missing required headers");
            return;
        }

        long timestamp;
        try {
            timestamp = Long.parseLong(timestampStr);
        } catch (NumberFormatException e) {
            sendError(response, "Invalid timestamp");
            return;
        }

        long currentTime = System.currentTimeMillis();
        // 2. 时间戳新鲜度校验
        if (Math.abs(currentTime - timestamp) > TIMESTAMP_WINDOW) {
            sendError(response, "Request expired or timestamp invalid");
            return;
        }

        // 3. 签名校验（此处需根据自身规则实现，确保nonce和timestamp参与签名）
        if (!verifySignature(request, nonce, timestamp, signature)) {
            sendError(response, "Invalid signature");
            return;
        }

        String redisKey = NONCE_PREFIX + nonce;
        // 4. Redis原子性校验：使用SETNX命令，如果key不存在则设置并返回true
        Boolean isNew = redisTemplate.opsForValue().setIfAbsent(redisKey, "1", Duration.ofSeconds(310));
        if (Boolean.FALSE.equals(isNew)) {
            // 随机数已存在，判定为重放攻击
            sendError(response, "Replay attack detected");
            return;
        }

        // 5. 验证通过，继续后续流程
        chain.doFilter(request, response);
    }

    private boolean verifySignature(HttpServletRequest request, String nonce, long timestamp, String clientSignature) {
        // 实现你的签名逻辑，例如将参数排序后拼接，然后用HMAC-SHA256计算签名
        // 必须包含nonce和timestamp
        // 返回计算出的签名与clientSignature是否一致
        return true; // 示例代码
    }

    private void sendError(HttpServletResponse response, String message) throws IOException {
        response.setStatus(HttpStatus.FORBIDDEN.value());
        response.getWriter().write(message);
    }
}

这个示例展示了在过滤器层面统一处理防重放逻辑。关键在于第4步，使用Redis的"SETNX"（set if not exist）指令进行原子性操作，完美解决了在高并发下可能出现的校验竞态条件问题。

四、应对高并发与性能优化的实践

在海量请求下，防重放缓存可能成为性能瓶颈。以下是几个优化方向：

1. 缓存Key的设计：使用"nonce:"作为前缀，清晰且易于管理。可以考虑将时间戳信息融入Key设计，例如按小时分片："nonce:2023101510:abcdef123456"。这样可以利用Redis的过期策略自动清理，也便于分片存储。

2. 内存优化：如果随机数很长，直接作为Key可能占用较多内存。可以考虑对其（如SHA-256）后存储哈希值，将固定长度的哈希值作为Key。

3. 异步写入与惰性清理：对于性能要求极高的场景，可以在校验通过后，将随机数放入一个内存队列，由后台线程异步写入Redis。同时，可以设置一个布隆过滤器（Bloom Filter）在Redis之前做一层快速预判，它能以极小的空间代价判断“某个随机数很可能不存在”，从而拦截绝大部分重复请求，仅对少数不确定的请求查询Redis，大幅降低Redis压力。

4. 容灾考虑：在Redis不可用时，应有降级方案。例如，可以暂时放宽时间戳窗口的校验，并记录告警，而不是直接拒绝所有请求导致服务不可用。但必须明确，降级期间安全风险会升高。

五、与整体API安全体系的协同

防重放随机数缓存不是孤立的安全措施，它必须与整个API安全体系联动才能发挥最大效力：

1. 与HTTPS配合：防重放机制保证了请求的唯一性，但前提是请求内容在传输中未被窃听和篡改。全站强制HTTPS（TLS 1.2+）是基础，它防止了中间人攻击，确保了随机数、时间戳和签名在传输中的机密性和完整性。

2. 与身份认证（Authentication）结合：防重放解决的是“请求是否重复”的问题，而“请求者是谁”需要身份认证来解决。通常使用API Key/Secret或OAuth 2.0令牌。防重放的缓存Key最好与客户端身份关联，例如"nonce:client_123:abcdef"，这样可以为不同客户端独立管理，也便于问题排查。

3. 与速率限制（Rate Limiting）互补：速率限制（如每分钟最多100次请求）能从频率上抑制攻击，而防重放则从唯一性上杜绝重放。两者结合，能有效应对从低频精准重放到高频暴力重放的各种攻击模式。它们可以共享同一个Redis实例，但使用不同的Key命名空间。

4. 完整的请求签名：如前所述，随机数和时间戳必须参与整个请求参数的签名计算。签名算法推荐使用HMAC-SHA256。签名应包含所有关键参数（包括请求体），并将签名结果放在请求头中。服务器端以同样规则计算并比对，确保请求在传输过程中未被篡改。

六、常见陷阱与最佳实践总结

在实施过程中，务必避开以下陷阱：

1. 客户端时钟不同步：如果用户设备时间严重不准，会导致时间戳校验失败。解决方案是，API可以返回服务器时间，客户端在后续请求中计算与服务器的时间差作为偏移量进行校准。

2. 随机数生成器的误用：在WebView或混合开发中，使用JavaScript的"Math.random()"生成随机数是极度不安全的，必须调用原生模块提供的安全随机数接口。

3. 缓存TTL设置过长或过短：过长会导致缓存积累，占用大量内存；过短可能导致合法请求在网络延迟稍高时被误判。建议设置为时间戳窗口期加上一个网络延迟余量（如30-60秒）。

4. 忽略异常流程：在业务处理失败或回滚时，要谨慎处理已存入缓存的随机数。一般来说，一旦随机数通过防重放校验存入缓存，即使业务失败也不应立即删除它，否则可能给攻击者留下短暂的时间窗口进行重放。应依靠TTL自然过期。

最佳实践总结：移动端API防重放是一个以“随机数”为弹药、“时间戳”为标尺、“分布式缓存”为阵地、“请求签名”为锁链的立体防御体系。它需要前后端协同设计，从客户端的安全生成与携带，到服务端的原子性校验与高效缓存，每一个环节都至关重要。将其作为API网关或统一过滤层的标准组件，能够为移动业务筑起一道应对重放攻击的坚固防线。

网站运营的移动端API的防重放随机数缓存

服务指南

帮助中心