记一次前端安全测试
字数 2031 2025-08-29 08:30:36

前端安全测试实战:从JS泄漏到管理员权限获取

一、案例背景

本案例涉及一个前端安全测试过程,目标网站具有以下安全防护措施:

  • 传输过程数据加密(无法直接重放或修改数据包)
  • 前端严格的输入限制
  • 关键业务逻辑由JavaScript控制

二、测试过程详解

2.1 敏感信息泄漏分析

发现过程

  1. 网站前端操作逻辑完全由JS控制
  2. 首次请求返回静态资源调用,随后JS向页面填充内容
  3. 传输数据加密处理

敏感信息提取

  1. 使用开发者工具直接查看JS代码
  2. 发现全网站请求路径及参数构造方式明文出现在JS中
  3. 使用jsfinder工具对38个JS文件进行URL匹配,发现779条URL

验证过程

  1. 将发现的URL放入Burp Suite进行存活探测
  2. 263个地址可直接访问
  3. 确认后端鉴权功能不完善,存在大量未授权访问风险

2.2 任意用户密码修改漏洞

漏洞发现

  1. 在泄漏的URL中发现/xx-password路径(密码修改功能)
  2. 未登录状态下填写数据点击确定无请求发出
  3. 登录后测试可正常修改密码

问题分析

  • 用于用户初次登录强制修改密码的接口未做访问限制
  • 登录状态下可不输入原密码直接修改新密码

深入测试

  1. 手动点击logout后再次测试可发出请求
  2. 发现与cookie相关机制:
    • 登录成功后服务器下发cookie
    • 前端JS提取cookie生成新的Access-Token请求头用于身份鉴别
    • 未登录状态无法提取token,故不触发请求事件
    • 登出后cookie未被删除,仍可生成token

加密机制分析

  1. 请求头已有失效的合法token,但返回用户类型错误
  2. 传输过程加密,无法直接改包测试
  3. 从参数构造入手,找到button绑定的click事件

核心加密函数分析

p(t, e) // 函数传入密钥(t)和待加密数据(e)两个值
  • 使用SM2算法对密钥加密
  • 使用AES算法对数据加密
  • 加密结果分别放入keycontent字段返回
  • 结构类似HTTPS模型:非对称算法加密密钥,对称算法加密数据

漏洞利用

  1. 写入普通用户的userIDuserType
  2. 放包后成功修改密码
  3. 后端验证逻辑缺陷:
    • 仅验证token真实性
    • 提取用户ID后直接进入修改密码流程
  4. 理论上可遍历管理员ID(生产环境风险高)
  5. 最终通过客户提供的管理员ID完成测试,成功修改管理员密码

2.3 漏洞链总结

  1. JS泄漏网站路径 →
  2. 敏感业务未授权访问 →
  3. 服务器弱鉴权机制 →
  4. 参数构造方法透明 →
  5. 获得web管理员权限

三、安全防护缺陷分析

  1. 前端代码透明性问题

    • 关键业务逻辑JS未做任何加固
    • 运行逻辑完全暴露
    • 敏感数据明文存储
  2. 后端权限设计缺陷

    • 接口访问控制不严格
    • 仅依赖前端生成的token验证
    • 缺乏多因素认证
  3. 加密机制失效

    • 虽然传输过程加密
    • 但加密方法完全暴露在前端
    • 参数构造方式透明

四、安全加固建议

4.1 前端代码安全

  1. 代码混淆

    • 使用专业工具对JS代码进行混淆
    • 包括变量名、函数名混淆
  2. 敏感信息保护

    • 不要将API路径、加密密钥等硬编码在前端
    • 必须在前端的敏感数据应进行二次加密
  3. 反调试措施

    • 检测开发者工具打开状态
    • 实现代码自校验机制
    • 使用代码碎片化加载

4.2 后端权限设计

  1. 严格的访问控制

    • 所有敏感接口必须验证会话状态
    • 实现基于角色的访问控制(RBAC)
    • 关键操作需二次认证
  2. Token验证增强

    • 使用JWT等标准token机制
    • 增加token绑定设备特征
    • 实现token短期有效性
  3. 操作审计

    • 记录所有敏感操作日志
    • 实现异常操作检测

4.3 加密传输改进

  1. 密钥管理

    • 避免前端硬加密密钥
    • 使用HTTPS+自有加密的双重保护
    • 实现密钥轮换机制
  2. 参数完整性验证

    • 增加参数签名机制
    • 服务端验证参数合法性
    • 防止参数篡改

五、测试方法论总结

  1. 前端代码审计

    • 系统分析所有JS文件
    • 提取隐藏的API路径和参数
    • 理解业务逻辑实现
  2. 接口探测

    • 对发现的API进行存活验证
    • 测试未授权访问可能性
  3. 加密机制逆向

    • 分析前端加密流程
    • 理解加密算法和密钥管理
    • 尝试构造合法请求
  4. 权限绕过测试

    • 测试token生成机制
    • 验证会话状态依赖项
    • 尝试权限提升

六、工具推荐

  1. 静态分析工具

    • jsfinder:JS文件URL提取
    • Burp Suite:API探测和测试
  2. 动态分析工具

    • Chrome开发者工具
    • Fiddler/Charles抓包工具
  3. 代码保护工具

    • JavaScript Obfuscator
    • JScrambler
    • Babel转换工具

七、总结

本案例展示了即使有严格的数据传输加密,前端代码的透明性仍可能成为系统安全的致命弱点。安全防护需要前后端协同配合,任何单点防护都可能被绕过。建议开发团队:

  1. 建立完整的安全开发生命周期(SDLC)
  2. 定期进行安全代码审计
  3. 实施严格的前端代码保护措施
  4. 加强后端接口的权限验证
  5. 进行定期的渗透测试和安全评估

通过系统性的安全防护,才能有效降低此类前端安全问题带来的风险。

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