V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
witcat
V2EX  ›  程序员

手机客户端一般怎么保护 api

  •  
  •   witcat · 2019-11-12 22:04:28 +08:00 · 4458 次点击
    这是一个创建于 1598 天前的主题,其中的信息可能已经有所发展或是发生改变。

    现在正在做一个小软件,主要内容是菜谱一类的。
    以前做的都是个人小作品,接口都不加密的。但因为这次的内容价值比较高所以想把安全做好一点。

    现在用了基本的 hmac 加密和 jwt
    其实我理解这个加密根本上依赖的就是 hmac 加密用的 secret (因为只要反编译了算法就是透明的)

    在小程序端做这个很简单,因为小程序有登录 api,可以在后端核实小程序的信息,然后返回 secret 和 token 给前端来加密请求。secret 是根据 token 在服务端生成的。

    我打算用 react native 继续做 iOS 和 Android 客户端,这样就不能用小程序那种方法了
    secret 肯定还是不能在前端存储或生成,rn 的客户端应该很容易反编译

    如果从服务器获取,也想不出来可以用什么凭证,
    一般大公司都怎么做呢?特殊的储存方法?还是?...想不出来了

    19 条回复    2019-11-13 10:02:30 +08:00
    cxtrinityy
        1
    cxtrinityy  
       2019-11-12 22:36:19 +08:00 via Android
    hmac 不是做完整性校验的?跟加密有什么关系
    和服务端交互上 https,客户端如果不联网,不管对称还是非对称加密,解密密钥肯定存在本地,你的内容真的值得别人反编译破解那总是有缺口在那
    如果客户端连网解密,密钥存服务端,AES 啥的就行
    bazingaterry
        2
    bazingaterry  
       2019-11-12 22:47:48 +08:00
    微信的 mmtls
    janus77
        3
    janus77  
       2019-11-12 22:48:48 +08:00
    安全这种东西是看成本的,就算你是商业产品,只要日活太少,不防一样没事。
    hkitdog
        4
    hkitdog  
       2019-11-12 22:51:20 +08:00 via iPhone
    参考抖音做法,自行研发一套基于 TCP 的传输协议,或者直接抄过去,抓包什么都看不到,Android 平台上,加密解密算法可以刻在内核上,最好自研,aes 这种烂大街就不要用了,经 IAT 动态调用,过程不经 Java 层,全用 C++写,在加个压缩刻基本很难逆
    hkitdog
        5
    hkitdog  
       2019-11-12 22:52:49 +08:00 via iPhone
    不想自己写的,用 360 加固吧,最低成本
    hadesy
        6
    hadesy  
       2019-11-12 22:54:50 +08:00
    各大加固厂商的密钥白盒了解下
    witcat
        7
    witcat  
    OP
       2019-11-12 22:59:20 +08:00
    @hkitdog #5 这个我看行 😂
    Foxkeh
        8
    Foxkeh  
       2019-11-12 23:01:02 +08:00 via iPhone
    ios 上我就留了三个
    过日子,健康养生,最近加了 懒饭
    你也是这一类的吗?期待你的作品。
    witcat
        9
    witcat  
    OP
       2019-11-12 23:02:34 +08:00
    @Foxkeh #8 鸡尾酒酒谱 类似 cocktail flow 但是是全中文的
    witcat
        10
    witcat  
    OP
       2019-11-12 23:12:12 +08:00
    @cxtrinityy #1 如果是需要联网的,AES 加密用的 key 也是存本地的吗?那这个 key 如果被反编译拿到是不是也可以随意伪造请求了。
    其实我就是想问一下有没有和小程序里那种一样低成本的方案,目前看是无解了,可能试试第三方加密。
    elarity
        11
    elarity  
       2019-11-12 23:17:56 +08:00
    murmur
        12
    murmur  
       2019-11-12 23:31:38 +08:00
    风控+律师团队+native 混淆级别的签名以及加密算法
    witcat
        13
    witcat  
    OP
       2019-11-12 23:50:09 +08:00
    @elarity #11 这个看起来不错,没有仔细看,作用是不是反爬作用更大?
    我是想验证客户端真实性,找一种可以动态获取 secret 保存在内存里的方法(不在客户端存储 key ),
    我现在主要想不通的就是怎么限制用户获取 secret,因为如果不鉴权,获取 secret 的接口调用是无限制的,这样任何安全都形同虚设了
    但是对于菜谱来说,不能强行要求用户登录才能看全部内容
    好像还是存在本地加固 app 靠谱一点
    eason1874
        14
    eason1874  
       2019-11-13 07:42:44 +08:00   ❤️ 2
    加固讲成本,破解也讲成本,把破解成本加大到一定程度就能让人失去破解的意愿了。

    数据价值特别高那就要求登录,通过 access_token 实现访问控制。数据价值一般高,那只要防抓包和防反编译就行了。防反编译可以用大厂的 APP 加固。防抓包纯粹 HTTPS 不够,可以每一个版本内置一个对称加密算法在 HTTPS 的基础上对请求进行二次签名。

    比如每次请求带一个时间戳+随机字符串当 token,APP 把 token 当密钥,APP 内置 API 版本算法将请求路径和请求参数算出一个签名加入到 headers 同时发送,服务器每次收到请求先验证时间戳,超过一定时间直接拒绝,然后根据请求内容验证 token,不对也直接拒绝,这样有人抓包了也不能重放,想修改参数就必须得破解 APP 拿到加密算法。

    每一个 API 版本都用不同的加密算法,要换算法直接禁 API 就行了,淘汰的 API 统一返回升级提示强迫用户升级 APP。
    chotow
        15
    chotow  
       2019-11-13 07:50:39 +08:00 via iPhone
    加密见其他楼层,我这里想到的是,用错误 token 请求接口时,不要返回报错,而是错误的内容,随机返回
    xuanbg
        16
    xuanbg  
       2019-11-13 08:01:56 +08:00
    楼主的需求是保护 API 不被盗用,这个说到底是没有万全的办法的。因为你不能确定用户来源,那么一切都只能是 open 的,也就意味着任何人都可以合法访问。

    唯一有效的办法是搞个 IP 黑名单,然后监控流量,流量异常的拉黑就是了 。
    eason1874
        17
    eason1874  
       2019-11-13 08:09:39 +08:00
    #14 补充一点。如果怕破解的人用自动工具通过 APP 一个个发送请求抓数据,那 APP 就再内置一个内容解密算法,和请求 token 转换内容密钥算法,APP 每次请求都把 token 转换成内容密钥一起传入回调处理用来解密返回的内容,服务器收到合法请求把 token 转换成内容密钥把响应内容加密返回,只返回加密内容就够了。
    elarity
        18
    elarity  
       2019-11-13 08:46:14 +08:00 via iPhone
    @witcat 既然是如此,我仔细琢磨了下,我觉得你需要的就是密钥协商。。。
    kangzai50136
        19
    kangzai50136  
       2019-11-13 10:02:30 +08:00
    C++写,java 层调用?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5343 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 08:08 · PVG 16:08 · LAX 01:08 · JFK 04:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.