前端安全测试实战：从JS泄漏到管理员权限获取<\/h1>

一、案例背景<\/h2>

本案例涉及一个前端安全测试过程，目标网站具有以下安全防护措施：<\/p>

传输过程数据加密（无法直接重放或修改数据包）<\/li>
前端严格的输入限制<\/li>

关键业务逻辑由JavaScript控制<\/li> <\/ul>

二、测试过程详解<\/h2>

2.1 敏感信息泄漏分析<\/h3>

发现过程<\/strong>：<\/p>

网站前端操作逻辑完全由JS控制<\/li>
首次请求返回静态资源调用，随后JS向页面填充内容<\/li>
传输数据加密处理<\/li> <\/ol>
敏感信息提取<\/strong>：<\/p>

使用开发者工具直接查看JS代码<\/li>
发现全网站请求路径及参数构造方式明文出现在JS中<\/li>
使用jsfinder工具对38个JS文件进行URL匹配，发现779条URL<\/li> <\/ol>
验证过程<\/strong>：<\/p>

将发现的URL放入Burp Suite进行存活探测<\/li>
263个地址可直接访问<\/li>
确认后端鉴权功能不完善，存在大量未授权访问风险<\/li> <\/ol>
2.2 任意用户密码修改漏洞<\/h3>
漏洞发现<\/strong>：<\/p>

在泄漏的URL中发现\/xx-password<\/code>路径（密码修改功能）<\/li>
未登录状态下填写数据点击确定无请求发出<\/li>
登录后测试可正常修改密码<\/li> <\/ol> 问题分析<\/strong>：<\/p> 用于用户初次登录强制修改密码的接口未做访问限制<\/li> 登录状态下可不输入原密码直接修改新密码<\/li> <\/ul> 深入测试<\/strong>：<\/p> 手动点击logout后再次测试可发出请求<\/li> 发现与cookie相关机制：登录成功后服务器下发cookie<\/li> 前端JS提取cookie生成新的Access-Token<\/code>请求头用于身份鉴别<\/li> 未登录状态无法提取token，故不触发请求事件<\/li> 登出后cookie未被删除，仍可生成token<\/li> <\/ul> <\/li> <\/ol> 加密机制分析<\/strong>：<\/p> 请求头已有失效的合法token，但返回用户类型错误<\/li> 传输过程加密，无法直接改包测试<\/li> 从参数构造入手，找到button绑定的click事件<\/li> <\/ol> 核心加密函数分析<\/strong>：<\/p> p<\/span>(t<\/span>, e<\/span>) \/\/ 函数传入密钥(t)和待加密数据(e)两个值 <\/span><\/span><\/span><\/code><\/pre> 使用SM2算法对密钥加密<\/li> 使用AES算法对数据加密<\/li> 加密结果分别放入key<\/code>和content<\/code>字段返回<\/li> 结构类似HTTPS模型：非对称算法加密密钥，对称算法加密数据<\/li> <\/ul> 漏洞利用<\/strong>：<\/p> 写入普通用户的userID<\/code>和userType<\/code><\/li> 放包后成功修改密码<\/li> 后端验证逻辑缺陷：仅验证token真实性<\/li> 提取用户ID后直接进入修改密码流程<\/li> <\/ul> <\/li> 理论上可遍历管理员ID（生产环境风险高）<\/li> 最终通过客户提供的管理员ID完成测试，成功修改管理员密码<\/li> <\/ol> 2.3 漏洞链总结<\/h3> JS泄漏网站路径 →<\/li> 敏感业务未授权访问 →<\/li> 服务器弱鉴权机制 →<\/li> 参数构造方法透明 →<\/li> 获得web管理员权限<\/li> <\/ol> 三、安全防护缺陷分析<\/h2> 前端代码透明性问题<\/strong>：<\/p> 关键业务逻辑JS未做任何加固<\/li> 运行逻辑完全暴露<\/li> 敏感数据明文存储<\/li> <\/ul> <\/li> 后端权限设计缺陷<\/strong>：<\/p> 接口访问控制不严格<\/li> 仅依赖前端生成的token验证<\/li> 缺乏多因素认证<\/li> <\/ul> <\/li> 加密机制失效<\/strong>：<\/p> 虽然传输过程加密<\/li> 但加密方法完全暴露在前端<\/li> 参数构造方式透明<\/li> <\/ul> <\/li> <\/ol> 四、安全加固建议<\/h2> 4.1 前端代码安全<\/h3> 代码混淆<\/strong>：<\/p> 使用专业工具对JS代码进行混淆<\/li> 包括变量名、函数名混淆<\/li> <\/ul> <\/li> 敏感信息保护<\/strong>：<\/p> 不要将API路径、加密密钥等硬编码在前端<\/li> 必须在前端的敏感数据应进行二次加密<\/li> <\/ul> <\/li> 反调试措施<\/strong>：<\/p> 检测开发者工具打开状态<\/li> 实现代码自校验机制<\/li> 使用代码碎片化加载<\/li> <\/ul> <\/li> <\/ol> 4.2 后端权限设计<\/h3> 严格的访问控制<\/strong>：<\/p> 所有敏感接口必须验证会话状态<\/li> 实现基于角色的访问控制(RBAC)<\/li> 关键操作需二次认证<\/li> <\/ul> <\/li> Token验证增强<\/strong>：<\/p> 使用JWT等标准token机制<\/li> 增加token绑定设备特征<\/li> 实现token短期有效性<\/li> <\/ul> <\/li> 操作审计<\/strong>：<\/p> 记录所有敏感操作日志<\/li> 实现异常操作检测<\/li> <\/ul> <\/li> <\/ol> 4.3 加密传输改进<\/h3> 密钥管理<\/strong>：<\/p> 避免前端硬加密密钥<\/li> 使用HTTPS+自有加密的双重保护<\/li> 实现密钥轮换机制<\/li> <\/ul> <\/li> 参数完整性验证<\/strong>：<\/p> 增加参数签名机制<\/li> 服务端验证参数合法性<\/li> 防止参数篡改<\/li> <\/ul> <\/li> <\/ol> 五、测试方法论总结<\/h2> 前端代码审计<\/strong>：<\/p> 系统分析所有JS文件<\/li> 提取隐藏的API路径和参数<\/li> 理解业务逻辑实现<\/li> <\/ul> <\/li> 接口探测<\/strong>：<\/p> 对发现的API进行存活验证<\/li> 测试未授权访问可能性<\/li> <\/ul> <\/li> 加密机制逆向<\/strong>：<\/p> 分析前端加密流程<\/li> 理解加密算法和密钥管理<\/li> 尝试构造合法请求<\/li> <\/ul> <\/li> 权限绕过测试<\/strong>：<\/p> 测试token生成机制<\/li> 验证会话状态依赖项<\/li> 尝试权限提升<\/li> <\/ul> <\/li> <\/ol> 六、工具推荐<\/h2> 静态分析工具<\/strong>：<\/p> jsfinder：JS文件URL提取<\/li> Burp Suite：API探测和测试<\/li> <\/ul> <\/li> 动态分析工具<\/strong>：<\/p> Chrome开发者工具<\/li> Fiddler\/Charles抓包工具<\/li> <\/ul> <\/li> 代码保护工具<\/strong>：<\/p> JavaScript Obfuscator<\/li> JScrambler<\/li> Babel转换工具<\/li> <\/ul> <\/li> <\/ol> 七、总结<\/h2> 本案例展示了即使有严格的数据传输加密，前端代码的透明性仍可能成为系统安全的致命弱点。安全防护需要前后端协同配合，任何单点防护都可能被绕过。建议开发团队：<\/p> 建立完整的安全开发生命周期(SDLC)<\/li> 定期进行安全代码审计<\/li> 实施严格的前端代码保护措施<\/li> 加强后端接口的权限验证<\/li> 进行定期的渗透测试和安全评估<\/li> <\/ol> 通过系统性的安全防护，才能有效降低此类前端安全问题带来的风险。<\/p>