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

App 接口数据安全一般怎么处理?

  •  
  •   kim2x · 2017-09-19 14:11:59 +08:00 · 12318 次点击
    这是一个创建于 2382 天前的主题,其中的信息可能已经有所发展或是发生改变。

    目前在开发一款 App,过程中发现客户端和服务端传输数据可能会发生数据泄漏或者安全隐患,服务端采用的是 java,以主流的框架开发的 spring 为主,数据传输以 http 协议,格式为 json,对于敏感数据做了部分的安全处理,在客户端进行了数据加密再进行传输,但是响应结果以 json 暴露了出来,感觉有点不放心,不知大佬们有啥手段可以处理,我通过抓包拦截其他 app 请求,发现其响应结果都是被处理了,看到都是乱码字符,V 友们友 app 开发经验的希望可以多交流知道。小弟恭候 V 友们!!!

    48 条回复    2017-09-21 08:37:17 +08:00
    zgbgx1
        1
    zgbgx1  
       2017-09-19 14:21:47 +08:00
    没做过 app 开发,但是返回的数据混淆或者加密的意义并不大
    安全,首先上 https 吧
    如果 你不像被直接抓包,就直接加密的字符串,再到 app 进行解密,这和前端解密应该是一个道理
    LeeSeoung
        2
    LeeSeoung  
       2017-09-19 14:22:30 +08:00   ❤️ 1
    乱码是上了 https 吧,https 也是可以通过在手机安装 fake 证书抓包的。。只要在你接口那边做到参数严格检查,校验数据完整,不被非法修改就够了吧。。返回明文密文关系不大,密文在你 app 内部还是要被解密,照样能被人拦截。。特别重要的。。上 tcp,自己定义套通信协议。。没人能看懂那种。。
    banksiae
        3
    banksiae  
       2017-09-19 14:22:47 +08:00
    pb 传输,减少数据包大小。数据加密,一般 aes,或者找个开源的算法改一下;
    hugedata
        4
    hugedata  
       2017-09-19 14:43:51 +08:00
    有 fiddler 在 https 也一样玩儿玩。不过有总比没有好,还是 https 先上了吧。123 楼建议均可以考虑。如果有富余的时间和精力的话,把用户行为加上吧,判断是否是机器人。加上黑名单 IP,比如垃圾邮件的黑名单,IDC 机房的黑名单之类的。哪儿有绝对安全的系统哦。唉。
    miaomiao0323
        5
    miaomiao0323  
       2017-09-19 14:44:27 +08:00
    传过去加密了,返回回来当然也可以加密啊,服务端加密,客户端解密,安卓的话算法和 key 不要用 java 写,写在 so 里
    zjw7sky
        6
    zjw7sky  
       2017-09-19 14:46:41 +08:00 via iPhone
    数据传输加密,解析解密,通用参数不加密
    pangliang
        7
    pangliang  
       2017-09-19 14:47:54 +08:00
    返回结果加密的意义真的不大, 就一个心里安慰而已
    zhouyou457
        8
    zhouyou457  
       2017-09-19 14:57:44 +08:00
    https 传输,敏感数据 base64 加密,再不行把数据打成 zip 包再用 base64 加密然后传输过去
    whatgui
        9
    whatgui  
       2017-09-19 15:05:19 +08:00
    https 解决你的一切问题。不要自己再去造轮子了。
    sunchen
        10
    sunchen  
       2017-09-19 15:12:13 +08:00
    @zhouyou457 base64 是编码。。。
    sunchen
        11
    sunchen  
       2017-09-19 15:16:48 +08:00   ❤️ 2
    1. 上 https, 加验证证书逻辑,防止中间人,
    2. 数据用 aes 之类的进行对称加密,可以和加密逻辑整体写到 so 里
    3. app 混淆加固做好,防止直接逆向和被 xposed 劫持
    sunchen
        12
    sunchen  
       2017-09-19 15:17:46 +08:00
    @banksiae protobuf 可以被逆向,不过数据字段需要猜一下才能对应起来
    sunchen
        13
    sunchen  
       2017-09-19 15:19:16 +08:00
    @hugedata 客户端对证书验证严格的话,中间人问题可以避免
    sunchen
        14
    sunchen  
       2017-09-19 15:20:35 +08:00
    @LeeSeoung xposed 直接 hook 协议解析的地方,dump 解析后的数据结构出来可破
    mornlight
        15
    mornlight  
       2017-09-19 15:22:05 +08:00   ❤️ 1
    如果是不想通信过程被窃听或篡改,部署 HTTPS 就行了。如果连被用户自己抓包都不想,就在客户端 Pin 证书。
    LeeSeoung
        16
    LeeSeoung  
       2017-09-19 15:24:05 +08:00
    @sunchen 不解析协议到数据结构,纯粹解析数据流执行对应条件分支。。我相信够恶心一部分逆向的了。。再保险点,把通讯过程放到 so,so 也做加密处理。。- -我觉得这么一套下来估计够呛了。
    hugedata
        17
    hugedata  
       2017-09-19 15:29:08 +08:00
    @sunchen 好吧,客户端,但是用 http 测试工具之类的来模仿客户端的话,就不存在“客户端对证书验证严格的话”这种情况了,比如写爬虫时分析对方的返回 json 数据的服务时,不都是这么干么。
    sunchen
        18
    sunchen  
       2017-09-19 15:36:52 +08:00
    @hugedata 服务端可以验证 API 的签名啊
    sunchen
        19
    sunchen  
       2017-09-19 15:38:56 +08:00
    @hugedata 其实客户端对证书验证严格的话,抓不到 https 的包,连 api 的参数都看不到的
    sumuu
        20
    sumuu  
       2017-09-19 15:41:37 +08:00
    我一般会从两个点去看待这样的问题.
    1. 数据是否必须强加密?
    很显然,不是什么数据都需要去加密,因为加密还是需要一定的成本.


    2. 如何加密

    AES 就好.


    接口数据安全的处理?
    1. 所有请求和响应都会把相关字段加密,生成一个 sign 的字段,然后 接受数据方需要做数据校正.
    2. 敏感信息,都是服务端加密,客户端无法解密.



    最后 HTTPS 是必须的,不是盲目崇拜 HTTPS,这个是基本,就像换衣服你得在家里等,不会在外面.
    kohos
        21
    kohos  
       2017-09-19 15:46:45 +08:00
    与其去想如何加密,不如去想如何在服务器端检查伪造数据和发包机器人。反正客户端都到用户手里,https 装个 fiddler 证书可以拦截,so 用 IDA 反编译也可以破解。市面也有不少安卓保护服务,但多逛逛看雪论坛也还是有不少被攻破的
    kohos
        22
    kohos  
       2017-09-19 15:50:09 +08:00
    补充一下 https 还是有必要上的,fiddler 只能拦截安装了破解证书的设备,其他人正常的设备一般是拦截不了的,就算在路由器网关上拦截到的包也是加密的
    janus77
        23
    janus77  
       2017-09-19 15:55:57 +08:00
    https
    参数加个自加密的签名
    服务器和本地时间校验
    限制重复请求次数
    l12ab
        24
    l12ab  
       2017-09-19 16:00:18 +08:00
    彻底的安全应该是没有,只能加大被破解的难度
    http,加上 Pin 证书校验,URl 混淆,参数混淆,带 token 参数
    vus520
        25
    vus520  
       2017-09-19 16:27:59 +08:00
    看了一下,都说 HTTPS 能防解密???乱说什么大实话。所有通信,只要是最终会解密的,都有可能泄露。HTTPS 只能解决传输过程中不被篡改。

    最安全的是,是请求加签名,通信做加密,其它的,就看遇到什么样的对手吧。
    whileFalse
        26
    whileFalse  
       2017-09-19 16:38:12 +08:00
    @vus520 #25 https + 客户端校验证书,客户端不被破解的情况下防解密。
    z1113456051
        27
    z1113456051  
       2017-09-19 17:30:56 +08:00
    不重要的参数加一个校验防止修改,重要的参数加密在传。
    Kaho
        28
    Kaho  
       2017-09-19 18:07:57 +08:00
    我这里是 aes + rsa.
    geelaw
        29
    geelaw  
       2017-09-19 20:40:25 +08:00
    上了 HTTPS 就没有别的需要做的了。

    你的程序能做的,用户都可以做。如果系统上没有一种隔离你的程序和其他程序的功能,那么你的程序能做的,其他程序也能。
    u5f20u98de
        30
    u5f20u98de  
       2017-09-19 20:56:58 +08:00
    通讯安全:
    tls+客户端强制证书校验,防止随便导入个信任证书就被抓包了。必要时可以进行双向 tls 认证。
    协议安全:
    1.对每个请求和回复进行摘要算法签名,附到包的结尾或者 header 里。实现过程需用 C 实现加大逆向分析难度,且算法也要复杂防止被暴力枚举出来,必要时可以对.so 加壳或者混淆。同时在 jni 调用时 C 的代码也要倒过来验证调用的 APP 是不是真正的 APP 防止被人直接拿来调用。
    2.对请求和回复参数进行加密(可选),处理方法可以参考上一条。
    kim2x
        31
    kim2x  
    OP
       2017-09-19 21:08:20 +08:00 via iPhone
    @zgbgx1 先上 Https
    kim2x
        32
    kim2x  
    OP
       2017-09-19 21:09:23 +08:00 via iPhone
    @LeeSeoung 目前就先 https 之前做法的确 客户端解包就完蛋了
    kim2x
        33
    kim2x  
    OP
       2017-09-19 21:09:56 +08:00 via iPhone
    @banksiae pb 没用 、不太清楚具体哪些好处
    kim2x
        34
    kim2x  
    OP
       2017-09-19 21:10:49 +08:00 via iPhone
    @hugedata 哈 先上 V 油门都说到的 https
    kim2x
        35
    kim2x  
    OP
       2017-09-19 21:11:59 +08:00 via iPhone
    @miaomiao0323 目前只在客户端传到服务端加密了 待修正
    kim2x
        36
    kim2x  
    OP
       2017-09-19 21:12:42 +08:00 via iPhone
    @pangliang 先安慰下自己嘛
    kim2x
        37
    kim2x  
    OP
       2017-09-19 21:13:27 +08:00 via iPhone
    @zhouyou457 base64 编码没啥用 ,
    kim2x
        38
    kim2x  
    OP
       2017-09-19 21:13:46 +08:00 via iPhone
    @whatgui 哈 基本都说到了这个
    wuhau
        39
    wuhau  
       2017-09-19 22:21:45 +08:00
    1. https.
    2. 签名认证。一般 md5(key1+key2+key3) // 可以按照实际情况更改,可以防止一般的修改数值重放攻击。
    3. app 加固,如果逆向出你的客户端协议,以上根本没卵用。
    4. 返回数值用 rsa/aes 这种加密,可以增加对流量包抓包分析的难度。
    5. 做好 api 权限控制,防止越权等情况出现。
    6. 服务器安全加固(做了这么多,服务器账号密码都是 root,这都说不过去吧。)

    =====
    如果有什么不对,和需要完善的地方,还请各位指正/补充
    imjeen
        40
    imjeen  
       2017-09-19 23:21:55 +08:00 via Android
    楼上很多说 HTTPS 协议,其实楼主想要的是 JWT 加密 JSON 格式数据
    kim2x
        41
    kim2x  
    OP
       2017-09-19 23:57:31 +08:00 via iPhone
    @imjeenHttps 是肯定的 、JWT 感觉不怎么有效果 这东西好像在服务队还是无状态的 不怎么安全
    cevincheung
        42
    cevincheung  
       2017-09-20 00:19:40 +08:00
    @LeeSeoung #2 SSL Pining + 内置二次封装的 SSL 处理包可破
    LeeSeoung
        43
    LeeSeoung  
       2017-09-20 09:15:59 +08:00   ❤️ 1
    @cevincheung 网上已经有针对 SSL Pining 的破解方法了,还是#29 说的对,只要你的程序能做的,别的程序也能做。如果你能做到破解成本大于破解后的收益就够了。。
    nicevar
        44
    nicevar  
       2017-09-20 09:50:43 +08:00
    看你想挡住多少人了,绝对的安全是没有的,https 还是很有必要的,另外自己把加密封装在 so 里,然后对 so 再进行处理,这样能挡住百分之九十的人了
    raptor
        45
    raptor  
       2017-09-20 11:31:11 +08:00
    HTTPS 可解决 80%的安全问题和至少 20%的其它妖蛾子问题(比如被运营商或路由器劫持之类)
    zhouyou457
        46
    zhouyou457  
       2017-09-20 11:36:34 +08:00
    @sunchen @kim2x 我的意思是把敏感数据封装。。用 base64 编码加密再用 https 传输。。至于怎么封装我就管不了了啊,我以前就直接打个 zip 然后 AES 加个密就行了。。最好在传输编码字符串的时候用 md5 鉴权
    q9S
        47
    q9S  
       2017-09-20 13:48:41 +08:00
    上 api 网关
    phx13ye
        48
    phx13ye  
       2017-09-21 08:37:17 +08:00
    https,用 httpclient 一般配置成绕过证书校验,自己实现一个 X509TrustManager 和 HostnameVerifier,这样还安全吗??
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1242 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 23:25 · PVG 07:25 · LAX 16:25 · JFK 19:25
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.