Yakit靶场-前端加密与签名绕过实战：从手动分析到热加载自动化

1. 前端加密与签名机制入门从手动分析开始第一次接触前端加密时我也被那些SHA256、RSA、AES之类的术语搞得头晕。但实际拆解后发现这些加密机制就像快递站的密码柜——看似复杂其实都有规律可循。以最常见的登录场景为例前端通常会对用户名和密码进行加密处理防止明文传输被窃取。手动分析加密逻辑时我习惯先打开浏览器开发者工具。在Yakit靶场的SHA256案例中通过查看源码就能发现关键信息密钥是1234123412341234加密方式是把username和password拼接后进行SHA256哈希。用CyberChef这类工具验证时输入usernameadminpasswordadmin123选择SHA256算法得到的哈希值fc4b936...与前端计算结果完全一致。签名绕过的核心原理在于服务端只是机械地验证签名是否匹配并不关心数据是否被篡改。当我们修改密码为666666时只需按相同规则重新计算签名值26976ad...替换原请求中的signature字段即可。这个过程暴露了一个常见漏洞如果加密逻辑完全暴露在前端攻击者就能伪造任意合法请求。2. 热加载自动化解放双手的实战技巧手动计算签名虽然可行但每次测试都要重复操作实在太低效。这时候Yakit的beforeRequest热加载功能就像个智能助手能自动完成这些机械工作。我写的第一个热加载脚本是这样的encryptData (packet) { body poc.GetHTTPPacketBody(packet) params json.loads(body) name params.username pass params.password key 31323334313233343132333431323334 //十六进制密钥 signText fusername${name}password${pass} sign codec.EncodeToHex(codec.HmacSha256(codec.DecodeHex(key), signText)) result f{username:${name},password:${pass},signature:${sign},key:${key}} return string(poc.ReplaceBody(packet, result, false)) }这个脚本的工作原理很简单拦截原始请求→提取账号密码→按规则计算签名→重构请求体。在Web Fuzzer模块加载后每次发送请求都会自动完成签名连爆破密码都变得轻松多了。实测发现处理100次登录尝试的时间从15分钟缩短到10秒效率提升近百倍。3. 复合加密场景的破解之道当遇到SHA256RSA双重加密时事情变得更有趣了。在Yakit靶场的这个关卡中前端先对数据做SHA256哈希再用RSA公钥加密。公钥通过接口动态获取/crypto/js/rsa/public/key这要求我们的热加载脚本必须具备联网能力getPubkey func() { rsp poc.HTTP(GET /crypto/js/rsa/public/key HTTP/1.1 Host: 127.0.0.1:8787) return poc.GetHTTPPacketBody(rsp) } encryptData (packet) { pemBytes getPubkey() //...SHA256加密部分同上... rsaSign codec.EncodeToHex(codec.RSAEncryptWithPKCS1v15(pemBytes, sha256sign)) //...重构请求体... }这种场景下有个坑要注意RSA加密有长度限制直接加密长文本会失败。好在签名值本身是固定长度的哈希值正好规避了这个问题。在测试中发现不同语言的RSA实现可能有差异比如有的默认使用PKCS1v1.5填充有的用OAEP需要根据实际情况调整。4. AES加密的攻防实战AES加密在前端应用中最常见Yakit靶场提供了CBC和ECB两种模式的案例。以CBC模式为例除了密钥1234123412341234外还需要关注IV初始化向量。有趣的是这个IV居然硬编码在前端encryptData (packet) { hexKey 31323334313233343132333431323334 hexIV 67ba30beaabf8ccfebeca655d487805a //...AES-CBC加密... body f{data: ${data},key: ${hexKey},iv: ${hexIV}} }ECB模式更简单连IV都不需要。但要注意这两种模式的安全性差异ECB就像用相同钥匙开的储物柜相同明文会产生相同密文而CBC模式通过IV引入随机性相同明文每次加密结果都不同。在渗透测试时如果发现使用ECB模式基本可以判定存在安全隐患。5. 加密环境下的SQL注入技巧最精彩的莫过于靶场中AES加密的SQL注入关卡。虽然请求数据被加密但后端解密后直接拼接SQL语句-- 原始语句 select * from vulin_users where username admin; -- 注入后 select * from vulin_users where username adminor 11--;通过Yakit热加载自动加密注入语句我们完全绕过了前端加密的防护。这里有个实用技巧先用正常请求获取加密格式再在热加载脚本中构造注入语句。配合sqlmap时需要在MITM中间件中加载热加载脚本让sqlmap的探测流量自动加密sqlmap.py -r http.txt --proxyhttp://127.0.0.1:8081 --batch -T vulin_users --dump6. 密钥协商的高级玩法当遇到服务端动态生成RSA密钥的场景时我最初的做法是每次请求前先获取公钥getPubkey func(host) { rsp poc.HTTP(fGET /crypto/js/rsa/generator HTTP/1.1 Host: ${host}) //...返回公钥... }后来发现更优雅的方案——使用Yakit的序列功能。第一个请求获取公钥第二个请求用提取的公钥加密数据。最妙的是mirrorHTTPFlow函数它能拦截整个通信过程mirrorHTTPFlow (req, rsp, params) { pem params.privateKey data codec.RSADecryptWithOAEP(pem, codec.DecodeBase64(body.data)) return string(data) }7. 混合加密体系的破解最后那个RSA加密AES密钥的关卡完美模拟了HTTPS的密钥交换过程。我的破解思路是获取服务端RSA公钥生成随机AES密钥和IV用RSA加密AES密钥用AES加密实际数据对应的热加载脚本就像个加密路由器rsaEncrypt (pem, data) { return codec.EncodeBase64(codec.RSAEncryptWithOAEP(pem, data)) } aesEncrypt (key, iv, data) { return codec.EncodeBase64(codec.AESGCMEncryptWithNonceSize12(key, data, iv)) }这套方案的精妙之处在于既处理了RSA加密的长度限制问题又利用了AES的高效性。在测试金融类App时经常能遇到类似的加密体系。