0x01 前言

今天领导甩来一个漏洞让复测，说是业务方不认（大概初测同事写的有点问题）。结果复测时一看，好家伙！人家在原本加密的参数上又套了层加密，活像高校论文查重——重复率太高？那就用翻译软件再翻一遍！

我： 😅

业务方： "我们加了双重加密，安全得很！"

我内心OS： 你不认漏洞，那你做防护干嘛？关键是——再套一层加密能防的住吗？

最新也是碰到挺多这样的案例，SQL注入？上加密！越权？上加密！XSS？上加密！仿佛加个密就能一键安全，殊不知攻击者连解密都省了——直接操作加密后的数据照样打。这就像给纸糊的防盗门，还自信满满地说"我们双重防护"，殊不知漏洞的本质是逻辑缺陷而非数据是否加密。尤其SQL注入，当时挺震惊，怎么sql也靠加密修，真以为安服就是脚本小子吗，加个密就拿你没办法了。

0x02 嗯...

一个标准的登录框，在获取短信前有图形验证码

从初测的数据包中发现貌似图形验证码并没有生效，只是虚晃一枪

同事的报告里边就只是简单的替换了一下加密后的验证码就提交了（横向短信轰炸）

确实有点歧义，导致了业务不认说有 5 次的限制

那就来看看怎么个事，嗯。怎么跟初测的有点不太一样哈

直接一个 XHR 断点，往前逆推找到了加密的地方，发现是在原基础上又套了一层

没错了，确实就是这块了

再看看 phoneNumber 参数的加密逻辑

就是一个简单的 aes，秘钥还写死在代码中（厚码）

直接控制台生成超过 5 个加密后的数据，证明其可以突破 5 次限制即可

window.aaa = function aaa() {    const phoneNumbers = Array.from({length: 8}, (_, i) => `1888888888${1 + i}`);    const results = [];     for (const number of phoneNumbers) {        const r = {            phoneNumber: Object(h["b"])(number, "xxx", "xxx),            isRegist: t,            source: "login",            code: (new Date()).getTime()        };        results.push(JSON.stringify(v["a"].rsaEncrypt2(r)));    }    return results; };

正常测试记得放一两个自己的手机号

也是成了

但是第 8 次就显示 ip 次数超限制了，让这个本来就水的洞显得更水了

X-Forwarded-For 绕过，结束

0x03 SQL 注入

经典的排序注入

这块业务的修复手段就做了防篡改，加了个 sign

但是技术不太精湛，没逆出 sign 值，但是直接可以打断点，在签名前在浏览器把数据改了

也算是成功绕过

后续也就麻烦点，但也是成功测出个库名证明危害。

0x04 总结

从安全防御的纵深性来看，签名和加密技术确实能够有效抵御自动化工具和插件的扫描，但这仅构建了第一道防线。前端加密虽然能增加一定安全性，但由于JS代码完全暴露在浏览器中，即使做了混淆处理，仍然存在被逆向破解的风险。如果说单纯依赖前端加密来掩盖漏洞必定是不可靠的。

原文始发于微信公众号（蓝云Sec）：加密补洞？您这是给漏水的船贴创可贴呢！