Authentication token被篡改导致越权访问

Question

在基于Token的身份认证机制中，若服务端未对JWT等认证令牌进行完整性校验或签名验证，攻击者可篡改Token中的用户身份声明（如sub、role字段），实现权限提升或横向越权访问。常见问题在于开发者误信客户端传递的Token内容，缺乏服务端有效校验机制，导致伪造Token绕过访问控制。

Answer 1

1. 基于Token的身份认证机制概述

在现代Web应用中，基于Token的身份认证（如JWT）已成为主流方案。其核心思想是：用户登录后，服务端生成一个包含用户身份信息的Token并返回给客户端；后续请求中，客户端携带该Token进行身份识别。

JWT（JSON Web Token）由三部分组成：Header、Payload 和 Signature。其中Signature用于验证Token的完整性与来源可信性。

若服务端未校验签名或直接信任客户端传入的Token内容，则攻击者可篡改Payload中的sub（主体）、role、admin等字段，实现权限提升或横向越权访问。

2. 攻击原理与常见漏洞场景

• 签名绕过（None Algorithm）：部分JWT库支持"alg": "none"，攻击者可将签名删除，伪造任意Token。
• 弱密钥或默认密钥：使用默认密钥（如"secret"）或弱密钥，易被暴力破解或字典攻击。
• 算法混淆（Algorithm Confusion）：服务器支持RS256但接受HS256，攻击者可用公钥作为HMAC密钥伪造签名。
• 未校验Claim字段：服务端未验证iss（签发者）、exp（过期时间）、nbf（生效时间），导致过期Token仍有效。
• 盲信客户端Token数据：开发者直接从Token中读取role字段判断权限，未在服务端做二次校验。

3. 漏洞分析流程图

```mermaid
graph TD
    A[客户端发送JWT] --> B{服务端是否验证签名?}
    B -- 否 --> C[接受伪造Token]
    B -- 是 --> D[解析Payload]
    D --> E{是否校验claim字段?}
    E -- 否 --> F[接受过期/非法Token]
    E -- 是 --> G[查询数据库验证用户状态]
    G --> H[执行业务逻辑]
    C --> I[权限提升/越权访问]
    F --> I
```
    

4. 实际攻击示例代码

以下为攻击者修改JWT Payload并重新签名的Python示例：

import jwt

# 原始payload
payload = {
    "sub": "user123",
    "role": "user",
    "exp": 1735689600
}

# 使用已知弱密钥伪造Token
secret = "secret"
fake_payload = payload.copy()
fake_payload['role'] = 'admin'  # 提权为管理员

# 生成伪造Token
forged_token = jwt.encode(fake_payload, secret, algorithm='HS256')
print("Forged JWT:", forged_token)

    

若服务端使用相同密钥且未校验角色合法性，该Token将被当作合法管理员身份处理。

5. 安全开发实践建议

检查项	安全建议
签名验证	必须调用库函数验证签名，禁用none算法
密钥管理	使用强密钥（≥32字符），定期轮换，避免硬编码
算法声明	明确指定预期算法（如强制使用RS256）
Claim校验	验证exp, iss, aud等标准字段
权限控制	服务端基于数据库而非Token字段判断权限
Token存储	前端应存于HttpOnly Cookie，防止XSS窃取
日志审计	记录Token使用行为，便于追踪异常访问
黑名单机制	登出时加入Redis黑名单，限制短期有效性

6. 防御性架构设计模式

为应对Token伪造风险，建议采用“双因子验证”架构：

1. 第一步：验证JWT签名与标准Claim。
2. 第二步：从Token中提取sub（用户ID），查询数据库获取当前真实角色与状态。
3. 第三步：结合RBAC模型进行细粒度权限决策。
4. 第四步：对敏感操作增加二次认证（如短信验证码）。
5. 第五步：所有鉴权逻辑封装在统一中间件中，避免分散实现。

通过此模式，即使Token被篡改，服务端仍能基于可信数据源做出正确授权判断。