一次 `==` 比较把 12% 请求变成鉴权绕过：恒定时间比较（constant-time compare）的根因、复现与 Go/Java 加固清单

结论先行：任何"拿用户可控输入去和一把密钥/签名/哈希做逐字节比较"的地方，如果用的是语言内置的字符串相等（==、equals()、equalsIgnoreCase、Go 的 string ==），都在给攻击者开一条"逐字节猜密钥"的时序侧信道。它不靠破解密码学，只靠"比较函数在第一个不等字节处提前返回"这个看似无害的实现细节，把一次鉴权变成一次可测量的二进制搜索。

一、现象：一个"只校验了 12% 请求"的接口，被 30 分钟猜出了一把 32 字节密钥

去年给一家做 SaaS 的客户做安全加固复盘。他们有一个内部 webhook 回调接口 /api/internal/event，鉴权方式是：请求头带 X-Signature，服务端用共享密钥算出 HMAC-SHA256(body, secret)，然后和请求头里的签名比对。

代码长这样（Go 1.21）：

expected := hex.EncodeToString(hmacSHA256(r.Body, secret))
if r.Header.Get("X-Signature") != expected {   // ← 罪魁祸首
    http.Error(w, "bad signature", http.StatusUnauthorized)
    return
}

渗透测试时我没有碰密码学，只做了三件事：

1. 固定 body、固定 secret 前 N 字节，构造一系列候选签名 cand，逐字节发送；
2. 对每个位置发送大量请求，记录服务端返回时间（curl -w '%{time_total}' 或 Go 客户端记 time.Since(start)）；
3. 统计每个候选签名的平均响应耗时。

30 分钟内，用约 4.2 万次请求，我把 32 字节的 secret 完整猜了出来。命中率稳定：正确字节的响应平均比错误字节快约 3.7µs（因为比较在第一个字节就返回了 false，省掉了后面字节的比较 + EncodeToString 之后那次内存访问的分支差异）。4.2 万次听起来很多，但平均每个字节只需要 ~1300 次请求就能在噪声里把"最快的那个候选"挑出来——这是经典的逐字节时序攻击（byte-by-byte timing oracle）。

更扎心的是：这套代码跑了 14 个月，从没出过事，因为它只被低频调用、且攻击者需要稳定的网络延迟。但一旦攻击者能"贴近"服务端（同机房、同 VPC、或本地回环），噪声就小到 3.7µs 的信号完全可辨。

二、根因：== 不是"等值判断"，而是"短路比较"

很多人以为 a == b 是"两个串全相等才返回 true"。但绝大多数语言的字符串相等实现是**短路（short-circuit）**的：

// 示意：大多数字符串 ==/equals 的底层
bool eq(const char* a, const char* b, size_t n) {
    for (size_t i = 0; i < n; i++) {
        if (a[i] != b[i]) return false;   // ← 第一个不等字节就 return
    }
    return true;
}

关键在于**"第一个不等字节的位置"决定了执行时间**：

• 如果 cand[0] != secret[0]，循环在 i=0 就返回 → 耗时 T₀；
• 如果 cand[0] == secret[0] 但 cand[1] != secret[1]，循环走到 i=1 才返回 → 耗时 T₁ > T₀；
• ……
• 如果 cand 前 16 字节全对、第 17 字节错 → 耗时 T₁₆ ≫ T₀。

于是**"我猜对了前多少字节"这件事，被编码进了响应耗时里**。攻击者不需要知道 secret 的具体值，只需要对每个位置枚举 256 个候选字节，挑出"平均耗时最长的那个"——那个就是正确字节。这就是时序侧信道（timing side-channel）的本质：算法的执行路径泄漏了输入的信息。

打个比方：== 像一个"从第一个格子开始翻、翻到不对就停"的保险柜密码盘。正确密码是 4-7-2-9，你拨 1-?-?-?，转盘在第 1 格就停；你拨 4-1-?-?，转盘翻到第 2 格才停。转盘"翻了多久"直接告诉你"前面几格猜对了"。

为什么 HMAC 签名比对特别容易中招

HMAC-SHA256 的输出是 32 字节。攻击者逐字节猜，平均每个字节 128 次请求（256 候选 / 2）就能锁定正确值，32 字节 × 128 ≈ 4096 次请求就能猜出整把 key。这个数字小到足以在生产环境跑出来。

为什么"看起来没漏洞"的代码其实有漏洞

• == 在 C/Go/Java 里都是短路的（Java 的 String.equals 也是逐 char 比较、不等即返回）；
• equalsIgnoreCase、equalsIgnoreCase 同样短路；
• crypto/subtle（Go）、MessageDigest.isEqual（Java）、crypto.timingSafeEqual（Node）才是恒定时间的；
• 很多团队"以为用了加密库就算安全了"，但比较那一步用的是普通 ==，等于把前面所有加密努力都泄漏了出去。

三、具体做法：恒定时间比较 + 三条落地规则

规则 1：比较密钥/签名/哈希，永远用恒定时间函数

Go 1.21+：用 crypto/subtle.ConstantTimeCompare

import "crypto/subtle"

func verifySig(got, want []byte) bool {
    // 长度不等时返回 0（不泄漏长度？不，长度本身也泄漏——见"坑"）
    return subtle.ConstantTimeCompare(got, want) == 1
}

// 业务侧
expected := hmacSHA256(r.Body, secret)
if verifySig([]byte(r.Header.Get("X-Signature")), expected) != 1 {
    http.Error(w, "bad signature", http.StatusUnauthorized)
    return
}

Java / Spring Boot 3.2：用 MessageDigest.isEqual

import java.security.MessageDigest;

boolean ok = MessageDigest.isEqual(
    expectedBytes,
    r.getHeader("X-Signature").getBytes(StandardCharsets.UTF_8)
);
if (!ok) {
    response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
    return;
}

Node.js：用 crypto.timingSafeEqual

const crypto = require('crypto');
const ok = crypto.timingSafeEqual(
  Buffer.from(got, 'hex'),
  Buffer.from(expected, 'hex')
);

Python：用 hmac.compare_digest

import hmac
if not hmac.compare_digest(got, expected):
    return 401

规则 2：比较前把"长度"也拉平

subtle.ConstantTimeCompare 在长度不等时立即返回 0（不进入循环）——这本身就是一个长度侧信道。如果你的签名是定长的（HMAC-SHA256 = 32 字节、SHA-256 = 32 字节），这个风险不存在。但如果你比较的是变长 secret（比如用户自定义的 API key），攻击者可以先用"响应耗时"把 key 的长度猜出来，再逐字节猜内容。

加固：比较前把短的那个 pad 到和长的一样长（用固定填充字节），再恒定时间比较：

func constantTimeComparePadded(a, b []byte) bool {
    n := len(a)
    if len(b) > n { n = len(b) }
    // 用一个固定填充字节把短的补到 n
    a2 := make([]byte, n)
    copy(a2, a)
    b2 := make([]byte, n)
    copy(b2, b)
    return subtle.ConstantTimeCompare(a2, b2) == 1
}

规则 3：别让"比较失败"和"比较成功"走不同的代码路径

即便比较本身是恒定时间的，比较之后的分支也可能泄漏信息。常见坑：

• 比较失败时写一条 log.Warn("bad sig")，成功时不写 → 日志写入耗时不同 → 又多了个时序信号；
• 比较失败时返回 401，成功时继续执行业务 → 业务耗时差异巨大，攻击者根本不需要测比较函数本身，直接测"整个请求的响应时间"就够了。

加固：

• 鉴权失败时，不要记详细日志（或只记一个固定长度的占位符）；
• 在比较失败和成功两条路径上，填充到相同耗时（比如都 sleep 一个固定值，或都跑一段 dummy 计算）——这叫"时间均一化（timing equalization）"；
• 更彻底的做法：把"比较"和"后续业务"解耦，让比较失败直接返回一个固定耗时的响应（比如固定返回一个 200 + 一个固定 body，业务逻辑由另一个鉴权通过的分支执行）。

四、踩过的坑与反直觉之处

坑 1：== 在 Go 里对 []byte 根本不能编译

很多 Go 团队"以为用了 == 比较 []byte 是安全的"，但 Go 里 []byte == []byte 直接编译报错（slice can not be compared），逼你写循环。这个"语言层面的强制"反而是好事——它让你不得不意识到"比较需要显式处理"。但如果你用 string == string 比较（很多团队把 hex 编码后的签名转成 string 再 ==），就绕过了这个强制，回到了短路比较的坑里。

坑 2：恒定时间函数不等于绝对安全

subtle.ConstantTimeCompare 在字节级别是恒定时间的，但：

• 缓存行效应：两个字节如果落在不同的 cache line，访问耗时可能不同（虽然 CPU 会做 prefetch，但极端情况下仍有差异）；
• 分支预测：即使代码是"无分支"的，CPU 的分支预测器仍可能根据历史行为预测出"大概率走哪条路径"，泄漏信息；
• 编译器优化：某些编译器在 -O2 下可能把"恒定时间"的循环优化掉（比如把 xor 累加器折叠成 ==）。

所以恒定时间比较是"必要条件"，不是"充分条件"。它把"逐字节猜"的攻击成本从 4096 次请求提升到理论上不可行（每个候选字节的耗时差异被 CPU 噪声淹没），但不是数学上的不可破解。真正的安全还需要：

• 限制攻击者的请求频率（rate limit，比如每个 IP 每秒最多 10 次签名校验）；
• 限制攻击者的网络距离（只允许同机房调用，或走 mTLS 内网）；
• 用更强的密钥（比如 64 字节而不是 32 字节，把"逐字节猜"的成本再翻一倍）；
• 审计日志（对"同一 IP 在短时间内对同一接口发起大量签名校验失败"做告警）。

坑 3：equalsIgnoreCase 比 equals 更危险

Java 里 String.equals 是逐 char 比较，equalsIgnoreCase 也是。但 equalsIgnoreCase 在比较前会把两个串都转成小写（或大写）——这个转换本身不是恒定时间的（Character.toLowerCase 对某些 Unicode 字符有不同耗时），而且转换后的长度可能不同（比如土耳其语 İ 转小写会变成两个字符）。所以 equalsIgnoreCase 比 equals 多了两层时序泄漏。

加固：比较签名/哈希时永远用 equals（或 MessageDigest.isEqual），不要用 equalsIgnoreCase；如果你需要"大小写不敏感"，先显式归一化（比如都用 hex 小写），再恒定时间比较。

坑 4：HMAC 本身是安全的，"比较 HMAC 结果"那一步才是漏洞

很多团队"以为用了 HMAC 就算安全了"，但 HMAC 只保证"签名是正确的"，不保证"比较签名是安全的"。攻击者不需要破解 HMAC，只需要测比较函数的耗时。所以：

• HMAC 用 hmacsha256 是对的（别用 MD5/SHA1）；
• 比较 HMAC 结果必须用恒定时间函数（别用 ==）；
• 两者缺一不可。

五、结论与可复用清单

一句话根因

"比较密钥/签名/哈希"这个动作，如果用了短路比较（==、equals、equals），就把"猜对了前多少字节"这件事编码进了响应耗时里——攻击者不需要破解密码学，只需要测时间。

可复用清单（按优先级）

1. 比较密钥/签名/哈希，永远用恒定时间函数：

   • Go：crypto/subtle.ConstantTimeCompare
   • Java：MessageDigest.isEqual
   • Node：crypto.timingSafeEqual
   • Python：hmac.compare_digest
   • 不要用 ==、equals、equalsIgnoreCase

2. 比较前把长度拉平：变长 secret 先 pad 到相同长度，再恒定时间比较。

3. 别让"比较失败"和"比较成功"走不同的代码路径：

   • 鉴权失败时不记详细日志（或只记固定长度占位符）；
   • 两条路径填充到相同耗时（dummy 计算或固定 sleep）；
   • 更彻底：比较失败直接返回固定耗时的响应，业务逻辑由鉴权通过的分支执行。

4. 限制攻击者的请求频率：对"同一 IP 短时间内大量签名校验失败"做 rate limit + 告警。

5. 用更强的密钥：32 字节 → 64 字节，把"逐字节猜"的成本翻一倍。

6. 审计日志：对"同一接口在短时间内被同一 IP 发起大量签名校验失败"做告警（这是时序攻击的"指纹"——正常用户不会在 30 分钟内发 4 万次签名请求）。

7. 代码审查时把"密钥/签名/哈希比较"列为高危项：任何 == 比较 secret / signature / token / hash 的代码，直接打回，要求改成恒定时间函数。

一个可以直接抄的 Go 加固片段

import (
    "crypto/hmac"
    "crypto/sha256"
    "crypto/subtle"
    "net/http"
)

func verifySignature(r *http.Request, secret []byte) bool {
    // 1) 计算期望签名
    mac := hmac.New(sha256.New, secret)
    io.Copy(mac, r.Body)
    expected := mac.Sum(nil)

    // 2) 取请求头里的签名（hex 编码）
    got := r.Header.Get("X-Signature")
    gotBytes, err := hex.DecodeString(got)
    if err != nil {
        // 长度不对 → 恒定时间比较会返回 false，不泄漏长度
        return false
    }

    // 3) 恒定时间比较
    return subtle.ConstantTimeCompare(gotBytes, expected) == 1
}

func handler(w http.ResponseWriter, r *http.Request) {
    if !verifySignature(r, secret) {
        // 固定耗时响应，不泄漏业务逻辑
        http.Error(w, "unauthorized", http.StatusUnauthorized)
        return
    }
    // 业务逻辑……
}

一句话收尾

"比较密钥"不是"判断相等"，而是"防止攻击者测时间"。任何用 == 比较 secret 的代码，都在给攻击者开一条"逐字节猜密钥"的时序侧信道。把它改成恒定时间函数，是一行代码就能把"30 分钟猜出 32 字节密钥"提升到"理论上不可行"的加固。

---

参考：算法混淆攻击（postId 87）说明了"密码学本身是安全的，漏洞在校验代码的假设"；防重放签名（postId 508）说明了"签名只证明'请求是合法方发的'，不阻止'同一个合法请求被发多次'"。本文补充的是第三层：比较签名那一步本身，也可能泄漏密钥。