1. 项目概述为什么你的接口总在“裸奔”最近在review团队里几个新项目的代码发现一个挺普遍的现象很多同学在写HTTP接口时对安全性的考虑还停留在“有HTTPS就够了”的阶段。结果就是接口要么被恶意调用刷数据要么请求参数被篡改导致业务逻辑错乱甚至还有因为重放攻击造成资金损失的案例。这让我想起几年前自己踩过的一个坑一个对外提供的支付回调接口就因为没做防重放凌晨被同一个请求刷了上百次虽然最后数据对上了没造成实际损失但那个排查的夜晚和心惊肉跳的感觉至今难忘。所以今天我想结合自己这些年在金融、电商等领域摸爬滚打的经验系统性地聊聊Java HTTP接口的安全实践。我们不止要讲清楚“加签验签”和“防重放攻击”这两个核心手段是什么更要深入拆解它们背后的原理、常见的实现“坑位”以及在实际生产环境中如何根据业务场景做权衡和设计。无论你是在做一个对内的微服务还是一个对外的开放平台API这些内容都是构建可靠服务的基础。如果你正被接口安全问题困扰或者想在面试中展现出你对安全实践的深入理解那么这篇内容应该能给你带来不少直接的参考。简单来说加签验签解决的是“请求是否来自可信方且未被篡改”的身份与完整性验证问题而防重放攻击解决的是“同一个有效的请求不能被重复使用”的时效性与唯一性问题。两者结合才能为你的HTTP接口构建起一道坚实的安全防线。2. 核心安全机制深度解析2.1 加签与验签不只是“对个暗号”很多人把加签验签理解成简单的“对暗号”这其实低估了它的价值。它的本质是利用密码学技术确保一段数据即HTTP请求的完整性和来源真实性。完整性确保从客户端发出到服务端接收的整个过程中请求的Body、关键Header等数据没有被任何人哪怕是网络传输设备篡改过。哪怕只改了一个字母验签就会失败。来源真实性确保这个请求确实来自你所声称的那个客户端即持有正确密钥的一方而不是一个冒名顶替者。这个过程通常依赖于非对称加密如RSA或对称加密如HMAC with SHA256算法。非对称加密使用公钥和私钥对私钥签名公钥验签常用于开放平台而对称加密双方共享同一个密钥计算速度快更适合内部系统。选择哪种取决于你的信任边界和性能要求。注意这里有个关键认知误区。加签验签不等于加密解密。加密是为了防止信息在传输过程中被窃听保密性而加签是为了防止信息被篡改或伪造完整性与真实性。一个请求可以同时被加密和签名这是两个维度的安全。2.2 防重放攻击给请求加上“一次性”标签防重放攻击英文叫Replay Attack。想象一下这个场景你拦截了一个用户“支付100元”的合法请求虽然你不能破解它的签名但你可以原封不动地把这个请求数据包在短时间内向服务器重复发送N次。如果服务器没有防护机制它每次都会认为这是一个新的、合法的支付请求从而导致用户被扣款N次100元。这就是重放攻击。防重放的核心思路是保证请求的唯一性和时效性。常见的实现方案有两种Nonce随机数 时间戳客户端每次请求生成一个全局唯一的随机字符串Nonce并附上当前时间戳。服务端收到后首先检查时间戳是否在可接受的时间窗口内如5分钟然后检查这个Nonce在时间窗口内是否已经被使用过需要缓存已使用的Nonce。如果时间戳过期或Nonce重复则拒绝请求。序列号为每个客户端分配一个递增的序列号每次请求序列号加1。服务端记录每个客户端最后收到的合法序列号只接受比当前记录更大的序列号请求。这种方式对客户端和服务端的状态维护要求更高。对于绝大多数业务场景“Nonce 时间戳”是更通用和简单的选择。它不需要维护长期的客户端状态通过时间窗口自然清理缓存实现起来也更轻量。3. 实战设计从理论到可落地方案3.1 整体架构与交互流程设计一个健壮的安全接口方案需要客户端和服务端紧密配合。我们不能只考虑服务端如何验证更要定义好客户端需要遵守的协议。下面是一个典型的、结合了加签和防重放的请求处理流程客户端发起请求时组装业务参数如JSON格式的body。生成当前时间戳timestamp单位秒或毫秒和一个全局唯一的随机字符串nonce可以用UUID。将业务参数、timestamp、nonce以及你的应用标识appId按照预定义的规则拼接成一个待签名字符串。这个规则必须双方约定一致通常按参数名ASCII码升序排列后以keyvalue的形式拼接。使用你的密钥对称密钥或私钥对这个字符串进行签名得到签名字符串sign。将appId,timestamp,nonce,sign以及业务参数通常放在HTTP Body中一同发送给服务端。签名相关参数一般放在HTTP Header里与业务解耦。服务端处理请求时防重放校验从Header中取出timestamp和nonce。先判断当前服务器时间与timestamp的差值是否在允许的窗口内如±5分钟。如果超时直接返回错误。接着以appId:nonce为key查询缓存如Redis中该nonce在时间窗口内是否已存在。若存在则是重放攻击拒绝请求若不存在则将appId:nonce写入缓存并设置过期时间为时间窗口的两倍如10分钟以确保覆盖整个有效周期。验签根据appId从数据库或配置中心获取对应的密钥。然后按照与客户端完全相同的规则将收到的业务参数、timestamp、nonce、appId拼接成待验签字符串。使用密钥计算签名并与客户端传来的sign进行比对。如果一致验签通过否则返回签名错误。只有通过了以上两步请求才会进入真正的业务逻辑处理。这个流程确保了请求是新鲜的、唯一的、完整的且来自可信客户端的。3.2 关键组件与工具选型在Java生态中我们有很多成熟的库可以帮助我们安全、高效地实现上述逻辑。密码学工具非对称签名RSAjava.security包中的Signature类。通常用于开放平台服务端持有公钥客户端持有私钥。// 使用SHA256WithRSA算法进行签名 Signature signature Signature.getInstance(SHA256WithRSA); signature.initSign(privateKey); signature.update(data.getBytes(StandardCharsets.UTF_8)); byte[] sign signature.sign(); String signStr Base64.getEncoder().encodeToString(sign);对称签名HMAC-SHA256javax.crypto包中的Mac类。内部系统常用双方共享同一个密钥。// 使用HmacSHA256算法进行签名 Mac mac Mac.getInstance(HmacSHA256); SecretKeySpec secretKeySpec new SecretKeySpec(secretKey.getBytes(StandardCharsets.UTF_8), HmacSHA256); mac.init(secretKeySpec); byte[] signBytes mac.doFinal(data.getBytes(StandardCharsets.UTF_8)); String signStr Hex.encodeHexString(signBytes); // 或Base64编码防重放缓存首选Redis由于其高性能和天然支持过期时间的特性是存储nonce的理想选择。可以使用SET key value EX 600 NX命令利用NX不存在才设置特性原子性地实现“存在即重复”的判断。内存缓存如Caffeine/Guava Cache仅适用于单机部署且流量不大的场景。在分布式环境下会失效不推荐生产环境使用。框架集成Spring MVC / Spring Boot通过实现HandlerInterceptor接口或使用ControllerAdvice配合自定义注解可以优雅地将安全校验逻辑以AOP的方式织入到HTTP请求处理链中避免业务代码被校验逻辑污染。自定义注解例如定义一个SignAuth注解将其加在需要校验的Controller方法上。拦截器检测到该注解则自动执行验签和防重放逻辑。4. 步步为营核心代码实现与详解光说不练假把式我们来看一个基于Spring Boot和HMAC-SHA256的简化版实现。我会重点解释容易出错的关键部分。4.1 定义安全协议与参数首先我们需要和客户端约定好通信协议。这里我们定义一个请求头规范头信息Header说明示例X-App-Id客户端应用唯一标识your_app_idX-Timestamp请求发起时间戳秒1715164800X-Nonce请求唯一随机串a1b2c3d4e5f6X-Signature对请求的签名2ef7bde608ce5404e97d5f042f95f89f1c232871待签名字符串的拼接规则为将appId,timestamp,nonce以及HTTP Body的原始字符串必须是原始未解析的字符串这点极其重要按参数名ASCII升序排列以连接键值对。例如appIdyour_app_idbody{orderId:123}noncea1b2c3d4e5f6×tamp17151648004.2 实现签名与验签工具类import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.StandardCharsets; import java.security.InvalidKeyException; import java.security.NoSuchAlgorithmException; import java.util.Base64; public class SignUtil { private static final String HMAC_SHA256 HmacSHA256; /** * 生成HMAC-SHA256签名 * param data 待签名字符串 * param secret 密钥 * return Base64编码的签名 */ public static String generateSignature(String data, String secret) { try { Mac mac Mac.getInstance(HMAC_SHA256); SecretKeySpec secretKeySpec new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), HMAC_SHA256); mac.init(secretKeySpec); byte[] hashBytes mac.doFinal(data.getBytes(StandardCharsets.UTF_8)); return Base64.getEncoder().encodeToString(hashBytes); } catch (NoSuchAlgorithmException | InvalidKeyException e) { throw new RuntimeException(生成签名失败, e); } } /** * 验证签名 * param data 待签名字符串 * param secret 密钥 * param clientSignature 客户端传来的签名 * return 是否验证通过 */ public static boolean verifySignature(String data, String secret, String clientSignature) { String serverSignature generateSignature(data, secret); // 使用恒定时间比较防止时序攻击 return MessageDigest.isEqual( serverSignature.getBytes(StandardCharsets.UTF_8), clientSignature.getBytes(StandardCharsets.UTF_8) ); } }关键点1恒定时间比较。上面的verifySignature方法中我使用了MessageDigest.isEqual而不是普通的String.equals()。这是因为普通的字符串比较在发现第一个不同字符时会立即返回false攻击者可以通过精确测量比较耗时来逐步猜测出正确的签名这种攻击称为“时序攻击”。MessageDigest.isEqual是恒定时间比较无论是否匹配执行时间都基本相同安全性更高。4.3 实现防重放校验服务import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.stereotype.Service; import java.util.concurrent.TimeUnit; Service public class ReplayAttackService { private final StringRedisTemplate redisTemplate; // 时间窗口单位秒 private static final long TIME_WINDOW 5 * 60; public ReplayAttackService(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } /** * 检查并记录Nonce防止重放 * param appId 应用ID * param nonce 随机数 * param timestamp 客户端时间戳 * return true: 通过校验 false: 重放攻击或超时 */ public boolean checkAndRecordNonce(String appId, String nonce, long timestamp) { long currentTime System.currentTimeMillis() / 1000; // 1. 检查时间戳是否在允许窗口内 if (Math.abs(currentTime - timestamp) TIME_WINDOW) { return false; } // 2. 检查Nonce是否已使用 String redisKey String.format(nonce:%s:%s, appId, nonce); // 使用SET NX EX命令原子性操作仅当key不存在时设置并设置过期时间 Boolean success redisTemplate.opsForValue().setIfAbsent(redisKey, 1, TIME_WINDOW * 2, TimeUnit.SECONDS); // 如果setIfAbsent返回false说明key已存在即Nonce重复 return Boolean.TRUE.equals(success); } }关键点2Redis键的设计与过期时间。这里将appId作为键的一部分是为了区分不同客户端的Nonce避免冲突。过期时间设置为时间窗口的两倍10分钟这是一个保险策略。假设一个请求在时间窗口的最后一秒第299秒到达它被记录后存活10分钟。那么在这10分钟内任何重放该Nonce的请求都会被拒绝。10分钟后这个请求早已超出5分钟的时间窗口即使Nonce缓存失效也会因时间戳过期而被拒绝。这确保了安全无死角。4.4 集成Spring拦截器最后我们将所有逻辑整合到一个Spring拦截器中。import com.fasterxml.jackson.databind.ObjectMapper; import org.springframework.web.servlet.HandlerInterceptor; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.util.Map; import java.util.TreeMap; import java.util.stream.Collectors; Component public class SecurityInterceptor implements HandlerInterceptor { private final ReplayAttackService replayAttackService; private final ObjectMapper objectMapper; // 用于读取Body // 假设有一个服务根据appId获取对应的secret private final AppSecretService appSecretService; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 获取Header中的安全参数 String appId request.getHeader(X-App-Id); String timestampStr request.getHeader(X-Timestamp); String nonce request.getHeader(X-Nonce); String clientSignature request.getHeader(X-Signature); // 基础校验 if (StringUtils.isAnyBlank(appId, timestampStr, nonce, clientSignature)) { response.setStatus(401); response.getWriter().write({\code\:\INVALID_REQUEST\, \message\:\缺少安全头部参数\}); return false; } long timestamp; try { timestamp Long.parseLong(timestampStr); } catch (NumberFormatException e) { response.setStatus(401); response.getWriter().write({\code\:\INVALID_REQUEST\, \message\:\时间戳格式错误\}); return false; } // 2. 防重放校验 if (!replayAttackService.checkAndRecordNonce(appId, nonce, timestamp)) { response.setStatus(401); response.getWriter().write({\code\:\REPLAY_ATTACK\, \message\:\请求重复或已过期\}); return false; } // 3. 获取请求Body关键 // 注意HttpServletRequest的InputStream只能读取一次需要包装 String requestBody request.getReader().lines().collect(Collectors.joining(System.lineSeparator())); // 或者使用ContentCachingRequestWrapper更优下文会讲 // 4. 获取该appId对应的密钥 String secret appSecretService.getSecretByAppId(appId); if (secret null) { response.setStatus(401); response.getWriter().write({\code\:\INVALID_APP_ID\, \message\:\无效的应用标识\}); return false; } // 5. 构建待签名字符串必须与客户端规则完全一致 MapString, String params new TreeMap(); // TreeMap自动按key排序 params.put(appId, appId); params.put(timestamp, timestampStr); params.put(nonce, nonce); if (StringUtils.isNotBlank(requestBody)) { params.put(body, requestBody); // 注意Body是作为整体字符串放入 } String dataToSign params.entrySet().stream() .map(entry - entry.getKey() entry.getValue()) .collect(Collectors.joining()); // 6. 验签 if (!SignUtil.verifySignature(dataToSign, secret, clientSignature)) { response.setStatus(401); response.getWriter().write({\code\:\INVALID_SIGNATURE\, \message\:\签名验证失败\}); return false; } // 7. 验签通过将必要信息放入请求属性供后续业务使用 request.setAttribute(appId, appId); // 注意Body已经被读取需要重新放回Request中供RequestBody解析 // 这就需要用到ContentCachingRequestWrapper return true; } }关键点3Request Body的读取陷阱。这是实现中最容易踩坑的地方。HttpServletRequest的getInputStream()或getReader()只能读取一次。如果在拦截器中读取了Body用于验签那么后续Spring的RequestBody注解将无法再获取到数据导致参数绑定失败。解决方案是使用ContentCachingRequestWrapper。你需要一个过滤器在最开始将原Request包装起来。import org.springframework.web.filter.OncePerRequestFilter; import javax.servlet.*; import javax.servlet.http.HttpServletRequest; import java.io.IOException; public class CacheRequestBodyFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { // 包装Request使其Body可重复读取 ContentCachingRequestWrapper wrappedRequest new ContentCachingRequestWrapper(request); filterChain.doFilter(wrappedRequest, response); } }然后在拦截器中通过((ContentCachingRequestWrapper) request).getContentAsByteArray()来获取Body内容。这样验签读一次后续Spring框架还能再读一次。5. 避坑指南与进阶思考在实际落地过程中你会遇到比示例代码复杂得多的情况。下面是我总结的几个核心“坑点”和进阶优化方向。5.1 常见问题与排查技巧验签总是失败先核对“待签名字符串”99%的验签问题都出在这里。务必确保服务端拼接字符串的规则、顺序、编码、内容与客户端完全一致。检查点参数排序规则ASCII升序最常见。Body的处理是取原始字符串包括空格、换行还是先JSON序列化再计算强烈建议使用原始字符串避免双方JSON库序列化差异如字段顺序、空格导致签名不一致。空值参数客户端是否参与签名服务端是否也按相同逻辑处理通常空字符串也需要参与拼接如key。URL编码问题如果参数值包含特殊字符是否需要URL编解码约定好统一标准。调试技巧在客户端和服务端分别打印出用于计算签名的原始字符串dataToSign进行逐字符比对。这是最直接的定位方法。时间戳同步问题客户端和服务端可能存在时钟不同步。时间窗口不宜设置过短如30秒否则正常的网络延迟也可能导致请求被拒绝。通常5分钟是一个比较平衡的选择。优化可以在API响应中返回服务器的当前时间戳客户端可以据此微调自己的时钟偏移量但这增加了复杂度。更简单的做法是适当放宽时间窗口并在服务端使用NTP保证时间准确。Nonce存储的并发与性能在高并发下对Redis的SET NX操作是安全的。但要考虑Redis集群部署下的问题确保nonce的存储和判断在同一个节点上通过合理的key设计或使用Redis集群的hash tag。内存考量每个有效的Nonce都会在Redis中存活一段时间如10分钟。需要根据你的QPS估算内存占用。QPS为1000则10分钟内最多存储1000*60060万个key这在现代Redis实例中是可以接受的。Body为空的POST请求或GET请求对于没有Body的请求如GET、DELETEbody参数不应出现在待签名字符串中或者其值应为空字符串。规则必须明确。对于application/x-www-form-urlencoded格式的POST参数可能同时在URL和Body中需要约定哪些参数参与签名通常全部。5.2 性能与扩展性优化签名计算性能HMAC-SHA256的计算开销很小通常不是瓶颈。RSA签名验证服务端用公钥验签比HMAC略慢但对于一般规模的API网关来说完全足够。如果遇到极端性能要求可以考虑在网关层使用硬件加速卡或者对非常频繁的接口采用更快的对称加密算法如HMAC-SHA256已经是很快的选择。密钥管理不要硬编码在代码里使用配置中心如Nacos、Apollo或密钥管理服务KMS来动态获取密钥。支持密钥轮转为每个appId配置主备密钥并在签名时携带密钥版本号。这样可以在不中断服务的情况下更新密钥。精细化控制上述拦截器是全局的。你可以结合自定义注解如SignAuth和Spring的拦截器匹配规则实现更精细的控制。例如给某些内部接口加上InternalApi注解跳过复杂的验签只做简单的IP白名单校验。监控与告警记录验签失败、重放攻击拦截的次数和来源IP。如果某个客户端在短时间内出现大量签名错误可能是其密钥泄露或代码有bug如果某个IP频繁触发重放攻击可能需要加入黑名单。这些日志是发现安全威胁的重要线索。5.3 面对更复杂的场景文件上传接口文件内容通常不直接参与签名因为文件太大。常见的做法是对文件的元信息如文件名、MD5值、大小进行签名或者对整个HTTP请求的其余部分Header、其他参数签名并在服务端收到文件后校验其MD5是否与签名参数中的一致。流式传输/长连接对于WebSocket或SSE上述基于请求/响应的模式不适用。通常会在连接建立时进行一次性的认证和密钥协商后续通信使用协商出的对称密钥进行加密和消息认证码MAC校验。开放平台的最佳实践除了签名还会结合OAuth 2.0等授权框架引入access_token来管理API调用的权限和生命周期。签名则用于保证access_token和请求本身的安全。接口安全是一个“道高一尺魔高一丈”的持续对抗过程。今天分享的加签验签和防重放是构建安全接口的基石能防御大多数常见的网络攻击。但安全不止于此还需要结合限流防刷、鉴权谁可以访问什么、输入校验防注入、日志审计等多种手段形成一个立体的防御体系。