浅析前端加密的常规解决思路

0x01前言

      大家在做渗透测试时总会遇到前端加密传输的情况，有时候这些加密确实令人烦心，老是影响我们大展身手，但这些加密只要花点时间细心分析其实也是很好解决的，本文就介绍了两个案例过程来阐释一些常规的解决手段和思路。

0x02过程方法

      从原理上来分析，前端加密的流程无非是通过JS将input的值进行加密，然后通过ajax传给后端进行处理，后端处理完要么返回明文给前端，要么返回加密结果给前端进行解密。那么根据此原理分析前端一定存在对应的加密算法，那么我们找到相关算法的话问题就迎刃而解。如何找到相关算法呢？有两种思路

（1）分析前端JS，查找加密函数。比较考验耐心

（2）在关键位置下断点，中断程序的执行。然后向上分析或者直接修改变量内容达到修改加密结果的操作。

以上两种思路都是为了我们能够找到加密算法然后修改数据进行渗透测试，我以近期我参与的一个项目为例

1. 分析前端JS:

在输入账号密码后可以看到我们的值被加密了，我们通过分析前端JS来确认加密函数。

通过浏览器的F12功能，我们搜索相关字符串，找到对应的JS代码，发现userName和其他被加密字段前都存在ENC.GetEnc函数。从字面上不难理解这是个加密函数，但是为了严谨我们可以通过控制台调用测试一下。

通过调用我们确定NC.GetEnc就是加密函数了。那么我就看看GetEnc函数怎么实现的吧。

那么我就看看GetEnc函数怎么实现的吧。

发现enc.js文件被混淆了。没关系，我们处理一下，就可以还原完整的加密过程了。

拿到加密函数后我们就可以通过该函数加密数据然后开展渗透测试了，通过结合burp中的JsEncrypter插件还可以批量爆破账号密码。当然这里就不展开讲了，大家可以去网上查阅相关资料。

B. 下断点分析处理:

上面A情况属于比较常见非常好处理的场景，但很多时候我们遇到的情况很复杂，例如现在很多前端资源都是用webpack打包了，非常影响我们分析，但是究其本质还是JS，我们可以通过一些开发思想进行调试处理。

如图所示，我们点击登录后数据包如下，所有的操作报文格式都如下，通过参数名不难猜出businessDate字段就是实际的业务字段。

照例我们还是打开浏览器的F12功能。出现的chunk以及main相关字眼，多半就是webpack打包处理了。而且这里面的语法参数都被混淆了，非常的反人类。

虽然代码被混淆的面目全非，但是我们还是可以寻找到一些关键字眼。前端页面传输数据给后台无非就是几类http方法，我们通过寻找接口地址找到关键位置。如图所示，我们搜索到了AJAX请求触发的位置。通过观察不难发现代码调用了a.a.post方法，第一个参数值是URL，剩余的未知，但是按照开发思想来判断后面的参数中有一个很大几率包含的明文值。我们在此处下断点，然后在前端进行操作，看是否能触发。

我们在前台操作后成功触发断点，触发断点后我们可以在控制台直接打印这几个值，也可以在Block域里面看到。

可以看到参数中的e就是我们传入的明文字段，我们在这里能直接看到明文说明加密是在下一步或者下一N步进行的，那我们在这里就可以修改我们的数据，相当于中间人劫持，在这里修改数据从而进行渗透测试。

当然我们也可以通过步进层层递进的追溯到加密方法，通过按快捷键F11即可层层步进。当然运气好几步就到了，运气不好F11按烂都找不到，通过分析可以确定到加密方法就是a.encryptedAes。然后我们继续跟进。

可以看到对应上述代码中的字段 c对应着明文字段，u对应着秘钥

当然拿到秘钥后我们也可以直接解密

也可以继续追溯加密算法。

也可以直接在解密位置下断点，解密返回后的加密值。

总之到这一步解决的方案就很多了。根据实际情况灵活选用即可。

0x03总结

随着前端技术的飞速发展和等保2.0的实施，这种加密传输的场景以后会越来越多，在以后遇到此类场景可尝试细心分析，参考以上两种方式再加上细心分析，百分之八十的前端场景都能解决。前端再无秘密。当然，解决加密只是第一步，后续是否能挖到漏洞更多还是考验综合技术以及人品运气。

原文始发于微信公众号（攻队）：浅析前端加密的常规解决思路