JWT验证存在漏洞：自定义JWT可成功调用后端API

看起来你遇到的核心问题是后端没有正确验证JWT的签名有效性——这是JWT认证最关键的一环，漏掉的话任何人都可以伪造合法token。下面是一步步的修复方案，都是生产环境中常用的实践：

1. 确保后端严格验证JWT的签名 #

JWT的核心是签名，后端必须用和签发时一致的密钥（或公钥，如果你用非对称加密的话）来验证token的完整性和真实性：

• 如果是对称加密算法（比如HS256）：
  • 绝对不能把签名密钥硬编码在代码里，要存在环境变量或者安全的配置管理系统中
  • 验证时必须使用完全相同的密钥，不能因为密钥写错或者验证逻辑跳过这一步导致签名验证失效
  • 示例代码（Node.js + jsonwebtoken为例）：

    const jwt = require('jsonwebtoken');
    const SECRET_KEY = process.env.JWT_SECRET; // 从环境变量取密钥
    
    function verifyToken(token) {
      try {
        // 必须指定算法，防止算法绕过漏洞
        return jwt.verify(token, SECRET_KEY, { algorithms: ['HS256'] });
      } catch (err) {
        // 验证失败，返回错误或拒绝请求
        throw new Error('Invalid JWT token');
      }
    }
    

• 如果是非对称加密算法（比如RS256）：
  • 签发用私钥，验证用对应的公钥，绝对不能把私钥暴露给前端或其他不可信环境
  • 验证时要确保使用正确的公钥，并且同样指定算法

2. 启用并验证JWT的标准声明（Claims） #

除了签名，还要验证token里的标准声明，防止篡改或滥用：

• exp（过期时间）：必须验证token是否过期，即使签名正确，过期的token也要拒绝
• iss（签发者）：验证token是否是你的后端服务签发的，防止其他系统的token被拿来使用
• aud（受众）：如果你的API有特定受众，验证token的aud是否匹配
• iat（签发时间）：可以验证token的签发时间是否在合理范围内，防止重放旧token（配合nonce更安全）

3. 修复可能的算法绕过漏洞 #

有些后端库如果不指定验证算法，会默认接受任何算法，攻击者可以把HS256的token改成none算法绕过验证。所以：

• 验证JWT时必须显式指定允许的算法，比如上面示例里的{ algorithms: ['HS256'] }
• 绝对不能启用none算法（除非是测试环境且严格隔离）

4. 加强JWT的签发规范 #

• 签发token时，尽量缩短过期时间（比如15-30分钟），配合刷新token机制，减少token泄露后的风险
• 刷新token要存在HttpOnly的Cookie里，不能存在前端localStorage，防止XSS攻击窃取
• 每个token可以加入唯一的jti（JWT ID），后端可以维护一个黑名单，当用户注销或修改密码时，把对应的jti加入黑名单，拒绝该token

5. 测试验证逻辑 #

修复后一定要做测试：

• 用正确的密钥签发的token可以正常访问API
• 自己伪造的token（哪怕结构正确但签名错误）会被拒绝
• 过期的token会被拒绝
• 修改了exp/iss等声明的token会被拒绝

最后再检查一遍你的后端验证逻辑，是不是哪里不小心跳过了签名验证步骤——很多时候都是因为开发时为了测试方便临时注释了验证代码，上线前没恢复导致的。

内容的提问来源于stack exchange，提问作者Dan