面经策

如何设计一个接口签名验证机制？防止参数被篡改和重放攻击？ ​

  • 标签：后端、系统设计、场景题、安全

🏛 业务架构师 ​

接口签名验证机制，我的回答是一套完整的签名协议设计，并强调密钥管理和体验两个容易被忽略的维度。

签名协议（标准三要素）

1. 参与方约定 app_id + app_secret(仅双方知道)
2. 请求组装: 所有参数按key排序 → k1=v1&k2=v2... 
   拼接 timestamp + nonce
3. sign = HMAC-SHA256(app_secret, 上述串)  → 随请求发送
   app_id, timestamp, nonce, sign

服务端校验四步

  1. 查密钥：按 app_id 找 secret（DB/缓存）
  2. 验时间窗：|now - timestamp| < 5 分钟——超时拒绝，限制重放窗口
  3. 验 nonce 一次性：SETNX nonce:{app_id}:{nonce} EX 300——窗口内同一 nonce 只认第一次（防重放）
  4. 重算签名比对：用相同规则重算，常量时间比较（防时序攻击）——参数被篡改任何一位，签名必不匹配

这套机制同时解决两个问题：防篡改（改参数签名失效）+ 防抵赖（只有持 secret 方能生成合法签名，开放平台的计费依据）。

工程与业务要点

  • 密钥管理是安全的地基：secret 分发安全通道、支持多密钥并存平滑轮换（新密钥生效旧密钥宽限期）、泄露应急吊销流程
  • 签名规则要文档化 + 提供多语言 SDK：开放平台的接入体验直接决定生态扩展速度——签名错误是第三方对接的第一拦路虎，错误提示要可诊断（"timestamp 超窗"而非笼统"签名错误"）
  • 不对称密钥升级（RSA/国密 SM2）用于更高安全等级场景：私钥签名公钥验签，双方不共享秘密
  • 配合 HTTPS 但不依赖：签名防的是"应用层伪造"，HTTPS 防链路窃听，层次不同都要有
  • 内部服务间用 mTLS/服务网格代替手工签名的趋势——签名机制主要保留给对外开放接口

收尾：签名机制上线后必须有监控大盘：按 app 的签名失败率——失败率突增往往是攻击探测或客户接错，前者要拦、后者要客服介入，安全机制也要运营化。

🏗 系统架构师 ​

接口签名验证 = 防篡改 + 防伪造 + 防重放三合一，我给完整方案与实现细节。

1. 签名算法设计

text
客户端：
1. 参数按 key 字典序排序，拼接成 k1=v1&k2=v2...（body 做 MD5 摘要参与）
2. 字符串 = method + path + sortedParams + timestamp + nonce
3. sign = HMAC-SHA256(appSecret, 字符串)，hex/base64
4. 请求头携带：X-App-Id, X-Timestamp, X-Nonce, X-Sign

服务端校验（顺序重要）：

  1. App-Id 合法性：查应用的 secret（缓存）
  2. 时间窗：|now - timestamp| ≤ 5 分钟，超时拒绝（把重放窗口框死）
  3. nonce 查重：Redis SETNX nonce:{appId}:{nonce}，TTL = 时间窗——存在即重放
  4. 重算签名比对：常量时间比较（防时序攻击，MessageDigest.isEqual），不一致 401

2. 设计要点与坑

  • HMAC 而非裸 MD5/SHA1：带密钥防伪造；secret 服务端与客户端分开保管，走 KMS 加密存储、支持轮换（双密钥并行的过渡期）
  • 参数规范化：排序规则、URL 编码、空值/数组参数的处理要与客户端 SDK 严格一致——签名不一致 90% 是规范化不一致，SDK 统一封装
  • body 签名：大 body 签 MD5 摘要而不是原文，JSON 序列化要稳定（字段序、空白）
  • 敏感头也参与签名：关键业务头（金额类）纳入签名范围
  • 时间偏移：客户端 NTP 校时；服务端允许 ±5 分钟由 nonce 兜底防重放

3. 防重放与签名的配合（与 95 题呼应）：timestamp 限窗口、nonce 保证窗口内唯一、sign 保证不可伪造，三者拆开都弱，合起来才完整。

4. 加固：签名失败的请求记入风控（同一 app_id 高频失败 → 封禁）；抓包可行但拿到 secret 才能伪造——客户端混淆/白盒加固提高逆向成本；重要接口叠加 mTLS（双向证书）做传输层身份认证。

💻 全栈开发专家 ​

接口签名我用标准三件套：timestamp + nonce + HMAC 签名，防篡改和防重放一起解决。

签名算法设计

text
1. 参数按 key 字典序排序，拼接成 k1=v1&k2=v2...
2. 拼接时间戳、nonce、body 摘要
3. stringToSign = METHOD + "\n" + PATH + "\n" + sortedQuery + "\n" + sha256(body) + "\n" + timestamp + "\n" + nonce
4. sign = Hex(HMAC-SHA256(appSecret, stringToSign))

服务端校验（顺序很重要）

java
if (Math.abs(now - timestamp) > 300_000) return reject("过期");     // 1. 时间窗
Boolean first = redis.opsForValue().setIfAbsent(
        "nonce:" + nonce, "1", 5, TimeUnit.MINUTES);                  // 2. nonce 去重
if (Boolean.FALSE.equals(first)) return reject("重放");
String expect = hmac(secret, buildStringToSign(req));                 // 3. 重算签名
if (!MessageDigest.isEqual(expect.getBytes(), sign.getBytes()))       // 常量时间比较
    return reject("签名错误");

先校验时间窗和 nonce（O(1) 拦截大部分），再算签名（省 CPU）；MessageDigest.isEqual 防时序攻击逐字节短路。

防篡改的关键

  • 签名覆盖完整请求：method、path、query、body 摘要一个不能少。见过事故：只签了 query，body 被篡改后签名依然合法。
  • secret 只存服务端：给前端页面的都是"token + 网关校验"，HMAC secret 是服务器间调用（开放 API）用的，绝不下发浏览器。

工程细节与坑

  • 参数值要做 URL 编码统一，否则客户端服务端拼接结果不一致，误判签名错误——排查时先 dump 两边 stringToSign 对比。
  • appSecret 支持多 key 平滑轮换（新 key 生效、旧 key 宽限期后禁用）。
  • 网关统一验签（APISIX jwt-auth/hmac-auth 插件），别每个服务重复实现。
  • 移动端加固：签名逻辑放 native so 并混淆，防抓包逆向拿 secret。