V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
luckykelan
V2EX  ›  信息安全

请教 客户端/前端的安全措施有什么意义?

  •  
  •   luckykelan · 152 天前 · 2548 次点击
    这是一个创建于 152 天前的主题,其中的信息可能已经有所发展或是发生改变。

    大家好,问题的背景是这样的:我们的项目已经上线了,但是竞争对手公司也在搞这方面,所以想尽可能的保护接口数据,最近做了以下尝试:

    1. mtls ,证书双向认证。但是客户端证书一直没有找到安全的存储方式,在客户端以硬编码存储,反编译以后就是明文了,以文件存储,将 APK 解压也会获取。
    2. 接口加密,我使用国密算法模拟了 https 的部分过程,在客户端/前端生成一组非对称加密密钥,用私钥进行签名,将签名后公钥传到后端,后端验签后会将对称加密的密钥使用传过来的公钥进行加密,返回到客户端/前端,后续的接口使用该密钥进行对称加解密。 虽然费了很大劲做了安全措施,但各位应该看出来了,其实破解起来并没有太大的难度 所以我的疑惑是客户端/前端的数据安全有办法保证吗?似乎不管用什么方式,破解起来都是体力工作...
    26 条回复    2024-07-03 01:01:24 +08:00
    foam
        1
    foam  
       152 天前 via Android
    就像捏柿子
    Helsing
        2
    Helsing  
       152 天前 via iPhone
    只要是客户端就没法保证绝对安全,因为拿到你的 apk 只要愿意花时间就总能破解

    简单有效的处理,换 Flutter 来写客户端,目前逆向比较难
    LeeReamond
        3
    LeeReamond  
       152 天前
    可能是个永恒难题,蹲一个答案。一个提高成本的方式是 wasm 编码部分运算过程吧,要解 wasm 还是比解 js 复杂不少的。还有就是算法是不是可以实现动态更新
    laofan666
        4
    laofan666  
       152 天前 via iPhone
    没做过这类需求,但是有个想法,
    服务端数据用私钥加密之后再加一些自定义的字符,客户端公钥解密之前先把字符去掉,
    这样即便公钥被破解也无法解密接口数据,
    客户端删字符的算法代码加点混淆,经过编译之后没那么容易破解
    0o0O0o0O0o
        5
    0o0O0o0O0o  
       152 天前 via iPhone
    客户端确实没有绝对安全,不过你描述中的防护约等于无,是要配合很多防护一起做的,常见的:反调反 hook 、混淆、代码虚拟、检测、反反编译、白盒…去买产品吧
    keakon
        6
    keakon  
       152 天前   ❤️ 1
    不是政治要求的话,那些国际通用的加密算法才是安全的。
    国密基本上是把这些算法拿来,将其中随机的参数设置成一个预设的常量,不但降低了安全性,还可能藏有后门。

    关于破解可以说没有任何安全的防御手段,前公司破解了大量竞争对手(网络安全行业)的产品来研究。

    关键是算法和数据才是有价值的,保护接口有啥意义?你看 OpenAI 不也开放了 API ,那么多开源模型都抄它的 API ,但是最终比的不是模型的质量么?
    MMM25O7lf09iR4ic
        7
    MMM25O7lf09iR4ic  
       151 天前
    你孱弱谁都可以欺负你所以你觉得大门不重要没安装,一个 200 斤的胖子可以过来揍你一顿,一个特种兵也可以过来一拳撩倒你,但是你不能某天早上睁开眼发现一个三岁小孩的鸡鸡对着你的脸撒尿。
    MMM25O7lf09iR4ic
        8
    MMM25O7lf09iR4ic  
       151 天前
    谈到有效的方案,有钱就买 360 企业版,代码混淆,接口数据加密,证书校验,没钱就 flutter ,但是这都是中小厂方案,其实你可以发现头部大厂的 apk 其实大部分是裸奔的,安全并不在客户端。
    dododada
        9
    dododada  
       151 天前
    接口没啥用,客户端要加固,梆梆,360 ,活着其他的,你们有能力就自己写。
    但是加固的话,每个版本可能都要重新适配
    InkStone
        10
    InkStone  
       151 天前
    客户端安全的原则是:破解利益<破解成本 === 安全。

    国密 tls 有现成的库,别想不开自己写……这玩意儿正确实现基本破解不了的。
    InkStone
        11
    InkStone  
       151 天前
    @erwsd32ew 头部大厂客户端大部分是局部加固的,主流做法是虚机方案。如果完全不做加固,黑产真的能把他们底裤都脱掉。
    shakeyo
        12
    shakeyo  
       151 天前   ❤️ 6
    @keakon ‘国密基本上是把这些算法拿来,将其中随机的参数设置成一个预设的常量,不但降低了安全性,还可能藏有后门‘ 能不能对你自己不懂的方向有点敬畏,搞技术的至少得做些研究再发言吧
    FengMubai
        13
    FengMubai  
       151 天前
    @laofan666 逆向你的自定义规则可比破解公钥简单多了
    FengMubai
        14
    FengMubai  
       151 天前
    客户端要保证数据安全, 只能让密钥只存在内存里
    FengMubai
        15
    FengMubai  
       151 天前
    @FengMubai #14 公钥除外
    jones2000
        16
    jones2000  
       151 天前
    能展示出来的数据,直接截图 AI 识别下,基本就能抓。
    meshell
        17
    meshell  
       151 天前
    写几个 SO 吧。难度加大 点。
    flyPig9527
        18
    flyPig9527  
       151 天前
    用户量不大一点必要都没有
    FengMubai
        19
    FengMubai  
       151 天前
    1. 双向证书没用

    2. 你把服务端公钥硬编码到客户端, 客户端生成对称密钥后, 携带 nonce, 一起用公钥加密发送到服务端, 服务端拿收到的对称密钥加密 nonce 返回
    sampeng
        20
    sampeng  
       151 天前
    1.双向认证安全那是两边都是服务端才有用
    2.前端安全措施从来都是防君子不防小人。增加破解成本,99%的破解的人你就是加个随机数就够他喝一壶的。这事没有什么绝对。n 年前微博的加密就在前端做的。逻辑我都翻出来了并套用到我自己公司的登录项目里面。但我依然破解不了微博的密码加密。因为他有 30 多个参数互相作用。。我人都给看傻了。再一个,就算我知道了怎么解密,第一道关就是怎么获取别的用户的流量而不是自己端的流量。。自己端的流量 https 都随便看,是无所谓的事。这道关可以拦截 99.99%的脚本战士
    BadFox
        21
    BadFox  
       151 天前
    增加攻击成本。单纯的双向证书只能说把门关了,人家一推就开。但就算只做到这一步你也可以拦住很多直接抓包改包的初级脚本小子了。配合反调反 hook ,混淆,反反编译等,就算是这么不仅关了还挂了个不错的锁,虽然别人也能破解但是成本骤然上升了很多。

    另外做安全不能以定性的思维来做,不能因为一个手段有可能被破解就觉得可以去掉。安全永远应该以定量的思维来分析,没有绝对的安全,但是我们能思考在付出一些可接受的代价的情况下可以安全到什么程度。
    hwf
        22
    hwf  
       151 天前
    可以说没有任何意义, 特别是想隐藏接口数据的
    tflins
        23
    tflins  
       151 天前
    增加攻击成本,就像只做一个简单的客户端加密或验证,也能杜绝大部分低成本的简单攻击
    monkeyk
        24
    monkeyk  
       151 天前
    所谓更安全就是增加复杂度;增加被拿捏的时间长度。
    ---- 做多年安全的总结
    snowgao
        25
    snowgao  
       151 天前 via Android
    就是典型的防君子不防小人
    luckykelan
        26
    luckykelan  
    OP
       138 天前
    非常感谢各位,学习到很多,谢谢
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   884 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 21:31 · PVG 05:31 · LAX 13:31 · JFK 16:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.