加密补洞？您这是给漏水的船贴创可贴呢！

Yu9·2025-04-11 00:07·12 分钟·3.2K·渗透测试

0x01 前言今天领导甩来一个漏洞让复测，说是业务方不认（大概初测同事写的有点问题）。结果复测时一看，好家伙！人家在原本加密的参数上又套了层加密，活像高校论文查重——重复率太高？那就用翻译软件再翻一遍！我： 😅业务方： "我们加了双重加密，安全得很！"我内心OS：你不认漏洞，那你做防护干嘛？关键是——再套一层加密能防的住吗？最新也是碰到挺多这样的案例，SQL注入？上加

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; 
};

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