1. 前端加密数据拦截的痛点与解决方案在渗透测试和安全评估工作中前端加密数据就像一堵无形的墙让安全工程师们头疼不已。想象一下当你用Burp Suite拦截到一个请求却发现所有关键参数都被加密成一串毫无意义的字符这时候连最基本的参数修改测试都无从下手。我遇到过不少项目使用AESRSA混合加密方案前端把用户名、密码等敏感字段加密后传输后端直接解密处理这种设计确实提升了安全性但却给安全测试带来了巨大挑战。Yakit的MITM热加载功能就像一把瑞士军刀能巧妙解决这个难题。它的核心原理是在中间人代理环节插入数据处理逻辑实现明文查看-修改-自动加密的完整工作流。举个例子当你在测试一个登录接口时前端用固定IV和Key的AES加密了密码字段传统做法可能需要手动解密修改再加密而通过Yakit可以自动化完成这个过程让你像操作普通HTTP请求一样测试加密接口。这种方案最大的优势在于保持原始通信加密强度的同时给安全测试开了个后门。实际测试中我经常用它来处理以下几种典型场景查看加密请求/响应的原始内容修改加密数据中的特定字段自动化重放加密请求批量测试加密接口的漏洞2. 环境准备与基础配置2.1 搭建测试环境工欲善其事必先利其器。我推荐使用docker-compose快速搭建一个带前端加密的测试环境version: 3 services: web: image: swagxz/encrypt-labs ports: - 8080:8080这个镜像模拟了常见的AESRSA前端加密场景正好用来演示Yakit的实战效果。启动后访问http://localhost:8080就能看到加密登录页面。2.2 Yakit基础配置首先确保Yakit版本在1.2.0以上老版本可能缺少某些关键功能。启动MITM代理时需要特别注意几个参数监听端口设置建议用8081等非常用端口避免冲突HTTPS证书安装一定要信任Yakit的根证书过滤规则建议初始阶段设置.*通配所有流量后期再细化我习惯用这个命令启动带热加载的MITMyak mitm --host 0.0.0.0 --port 8081 --hot-patch3. 加解密模块的配置技巧3.1 固定密钥的AES加解密面对固定Key和IV的AES加密我们可以利用Yakit的codec模块创建可复用的加解密单元。假设加密流程是明文→AES加密→Base64编码那么解密就需要逆向这个过程。创建decode_base64_AES模块时有个坑我踩过好几次AES输出格式要选raw而不是hex。配置参数应该这样填输入编码Base64解密算法AES-CBC密钥类型RawIV类型Raw填充模式PKCS7对应的encode_AES_base64模块则是反向配置。测试时可以用Yakit的即时编解码功能验证模块是否正确输入加密数据看能否解出明文。3.2 处理动态密钥场景有些系统会采用每次请求更换密钥的方案这种情况需要结合RSA解密来获取AES密钥。Yakit的codec模块支持链式调用可以这样配置先用RSA私钥解密出AES密钥用这个密钥解密请求体修改参数后重新加密虽然流程复杂些但原理相通。关键是要在hijackHTTPRequest和beforeRequest两个hook点分别处理解密和加密逻辑。4. MITM热加载的实战脚本4.1 历史记录明文存储让History展示明文数据是个非常实用的功能配置hijackSaveHTTPFlow时要注意几点dec_base64_aes func(data){ aa {{codecflow(decode_base64_AES| data )}} return fuzz.Strings(aa)[0] } hijackSaveHTTPFlow func(flow, modify, drop) { req codec.StrconvUnquote(flow.Request)~ // 只处理POST请求且包含加密字段的流量 if poc.GetHTTPRequestMethod(req) POST str.Contains(string(req), encryptedData){ postParams poc.ExtractPostParams(req)~ postParams[encryptedData] dec_base64_aes(postParams[encryptedData]) flow.Request codec.StrconvQuote(poc.ReplaceHTTPPacketJsonBody(req, postParams)) } modify(flow) }这段代码的精妙之处在于它只修改了存储到历史记录的数据不影响实际传输的密文。我在实际使用中发现对响应包做同样处理能极大提升测试效率特别是当接口返回加密的错误信息时。4.2 实时拦截与修改要实现明文修改-自动加密的完整流程需要组合使用三个hook函数// 请求到达Yakit时解密 hijackHTTPRequest func(isHttps, url, req, forward, drop) { if isTargetRequest(req) { decrypted decryptRequest(req) forward(decrypted) } else { forward(req) } } // 请求发往服务器前加密 beforeRequest func(ishttps, oreq, req){ if isTargetRequest(req) { return encryptRequest(req) } return req } // 辅助函数判断是否目标请求 isTargetRequest func(req) { return poc.GetHTTPRequestMethod(req) POST str.Contains(string(req), encryptedData) }这种分层处理的设计让逻辑更清晰也便于调试。记得在beforeRequest里重新加密时要确保加密参数与前端完全一致否则会导致后端解密失败。5. 调试技巧与常见问题5.1 Yak Runner实时调试热加载脚本出错时Yak Runner是排查问题的利器。我通常这样做复制热加载脚本到Yak Runner构造测试请求数据逐步执行每个函数查看中间变量值例如测试解密函数时testData : U2FsdGVkX13C7JjJ8i7VJQz7JjJ8i7VJQz7JjJ8 println(dec_base64_aes(testData))5.2 高频踩坑点根据我的经验新手常会遇到这些问题加密结果与前端不一致检查IV和Key是否完全一致确认加密模式(CBC/ECB等)和填充方式验证Base64编码规则(是否带padding)修改后请求被服务器拒绝检查Content-Length是否更新验证JSON格式是否合法确认加密字段是否包含修改后的全部参数HTTPS证书错误确保设备信任了Yakit根证书检查是否有证书固定(Pinning)机制尝试关闭HSTS保护有个项目让我记忆犹新前端使用了非标准的Base64编码表导致我花了整整一天才找出解密失败的原因。后来我养成了个好习惯先用浏览器的开发者工具记录下加密全流程再在Yakit中完全复现这个流程。