Android敏感数据泄露引发的思考

标签: | 发表时间:2020-10-11 08:18 | 作者:
出处:https://juejin.im

1.事件始末

一个平淡的午后,我还悠哉悠哉的敲着代码品着茶。突然服务端同事告诉我,关注接口正在被机械式调用,怀疑是有人在使用脚本刷接口(目的主要是从平台导流)。
纳尼?不会吧,因为据我所知接口请求是做了加密处理的,除非知道加密的密钥和加密方式,不然是不会调用成功的,一定是你感觉错了。然而当服务端同事把接口调用日志发给我看时,彻底否定了我的侥幸心理。

  1. 接口调用频率固定为 1s一次
  2. 被关注者的 id每次调用依次加一(目前业务上用户id的生成是按照注册时间依次递增的)
  3. 加密的 密钥始终使用固定的一个(正常的是在固定的几个密钥中每次会随机使用一个)

综合以上三点就可以断定,肯定是存在刷接口的行为了。

2.事件分析

既然上述刷接口的行为成立,也就意味着密钥和加密方式被对方知道了,原因无非是以下两点:

  1. 内部人员泄露
  2. apk被破解

经过确认基本排除了第一点,那就只剩下apk被破解了,可是apk发布出去的包是进行过加固和混淆处理的,难道对方脱壳了?不管三七二十一,自己先来反编译试试。于是乎从最近发布的版本一个一个去反编译,最后在反编译到较早前的一个版本时发现,保存密钥和加密的工具类居然源码完全暴露了。 反编译出来的加密工具类部分炸了锅了,排查了一下这个版本居然未加固过就发布出去了,而且这个加密工具类未被混淆。虽然还不太清楚对方是不是按照这种方式获取的密钥和加密算法,但无疑这是客户端存在的一个安全漏洞。

3.事件处理

既然已经发现了上述问题,那就要想办法解决。首先不考虑加固,如何尽最大可能保证客户端中的敏感数据不泄露?另一方面即使对方想要破解,也要想办法设障,增大破解难度。想到这里基本就大致确定了一个思路: 使用NDK,将敏感数据和加密方式放到native层,因为C++代码编译后生成的so库是一个二进制文件,这无疑会增加破解的难度。利用这个特性,可以将客户端的敏感数据写在C++代码中,从而增强应用的安全性。说干就干吧!!!


1.首先创建了加密工具类:

      public class HttpKeyUtil {
    static {
        System.loadLibrary("jniSecret");
    }
    //根据随机值去获取密钥
    public static native String getHttpSecretKey(int index);
    //将待加密的数据传入,返回加密后的结果
    public static native String getSecretValue(byte[] bytes);
}复制代码

2.生成相应的头文件:
com_test_util_HttpKeyUtil.h

      #include <jni.h>
#ifndef _Included_com_test_util_HttpKeyUtil
#define _Included_com_test_util_HttpKeyUtil
#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT jstring JNICALL Java_com_esky_common_component_util_HttpKeyUtil_getHttpSecretKey
        (JNIEnv *, jclass, jint);
        
JNIEXPORT jstring JNICALL Java_com_test_util_HttpKeyUtil_getSecretValue
        (JNIEnv *, jclass, jbyteArray);

#ifdef __cplusplus
}
#endif
#endif复制代码

3.编写相应的cpp文件:
在相应的Module中创建jni目录,将 com_test_util_HttpKeyUtil.h拷贝进来,然后再创建 com_test_util_HttpKeyUtil.cpp文件 jni

      #include <jni.h>
#include <cstring>
#include <malloc.h>
#include "com_test_util_HttpKeyUtil.h"

extern "C"
const char *KEY1 = "密钥1";
const char *KEY2 = "密钥2";
const char *KEY3 = "密钥3";
const char *UNKNOWN = "unknown";

jstring toMd5(JNIEnv *pEnv, jbyteArray pArray);

extern "C" JNIEXPORT jstring JNICALL Java_com_test_util_HttpKeyUtil_getHttpSecretKey
        (JNIEnv *env, jclass cls, jint index) {
    if (随机数条件1) {
        return env->NewStringUTF(KEY1);
    } else if (随机数条件2) {
        return env->NewStringUTF(KEY2);
    } else if (随机数条件3) {
        return env->NewStringUTF(KEY3);
    } else {
        return env->NewStringUTF(UNKNOWN);
    }
}

extern "C" JNIEXPORT jstring JNICALL
Java_com_test_util_HttpKeyUtil_getSecretValue
        (JNIEnv *env, jclass cls, jbyteArray jbyteArray1) {
        //加密算法各有不同,这里我就用md5做个示范
        return toMd5(env, jbyteArray1);
}

//md5
jstring toMd5(JNIEnv *env, jbyteArray source) {
    // MessageDigest
    jclass classMessageDigest = env->FindClass("java/security/MessageDigest");
    // MessageDigest.getInstance()
    jmethodID midGetInstance = env->GetStaticMethodID(classMessageDigest, "getInstance",
                                                      "(Ljava/lang/String;)Ljava/security/MessageDigest;");
    // MessageDigest object
    jobject objMessageDigest = env->CallStaticObjectMethod(classMessageDigest, midGetInstance,
                                                           env->NewStringUTF("md5"));

    jmethodID midUpdate = env->GetMethodID(classMessageDigest, "update", "([B)V");
    env->CallVoidMethod(objMessageDigest, midUpdate, source);

    // Digest
    jmethodID midDigest = env->GetMethodID(classMessageDigest, "digest", "()[B");
    jbyteArray objArraySign = (jbyteArray) env->CallObjectMethod(objMessageDigest, midDigest);

    jsize intArrayLength = env->GetArrayLength(objArraySign);
    jbyte *byte_array_elements = env->GetByteArrayElements(objArraySign, NULL);
    size_t length = (size_t) intArrayLength * 2 + 1;
    char *char_result = (char *) malloc(length);
    memset(char_result, 0, length);
    toHexStr((const char *) byte_array_elements, char_result, intArrayLength);
    // 在末尾补\0
    *(char_result + intArrayLength * 2) = '\0';
    jstring stringResult = env->NewStringUTF(char_result);
    // release
    env->ReleaseByteArrayElements(objArraySign, byte_array_elements, JNI_ABORT);
    // 指针
    free(char_result);
    return stringResult;
}

//转换为16进制字符串
void toHexStr(const char *source, char *dest, int sourceLen) {
    short i;
    char highByte, lowByte;
    for (i = 0; i < sourceLen; i++) {
        highByte = source[i] >> 4;
        lowByte = (char) (source[i] & 0x0f);
        highByte += 0x30;
        if (highByte > 0x39) {
            dest[i * 2] = (char) (highByte + 0x07);
        } else {
            dest[i * 2] = highByte;
        }
        lowByte += 0x30;
        if (lowByte > 0x39) {
            dest[i * 2 + 1] = (char) (lowByte + 0x07);
        } else {
            dest[i * 2 + 1] = lowByte;
        }
    }
}复制代码

4.事件就此结束?

到这里就此结束了?too yuang too simple!!!虽然将密钥和加密算法写在了c++中,貌似好像是比较安全了。但是但是万一别人反编译后,拿到c++代码最终生成的so库,然后直接调用so库里的方法去获取密钥并调用加密方法怎么破?看来我们还是要加一步身份校验才行:即在native层对应用的包名、签名进行鉴权校验,校验通过才返回正确结果。下面就是获取apk包名和签名校验的代码:

      const char *PACKAGE_NAME = "你的ApplicationId";
//(签名的md5值自己可以写方法获取,或者用签名工具直接获取,一般对接微信sdk的时候也会要应用签名的MD5值)
const char *SIGN_MD5 = "你的应用签名的MD5值注意是大写";

//获取Application实例
jobject getApplication(JNIEnv *env) {
    jobject application = NULL;
    //这里是你的Application的类路径,混淆时注意不要混淆该类和该类获取实例的方法比如getInstance
    jclass baseapplication_clz = env->FindClass("com/test/component/BaseApplication");
    if (baseapplication_clz != NULL) {
        jmethodID currentApplication = env->GetStaticMethodID(
                baseapplication_clz, "getInstance",
                "()Lcom/test/component/BaseApplication;");
        if (currentApplication != NULL) {
            application = env->CallStaticObjectMethod(baseapplication_clz, currentApplication);
        }
        env->DeleteLocalRef(baseapplication_clz);
    }
    return application;
}


bool isRight = false;
//获取应用签名的MD5值并判断是否与本应用的一致
jboolean getSignature(JNIEnv *env) {
    LOGD("getSignature isRight: %d", isRight ? 1 : 0);
    if (!isRight) {//避免每次都进行校验浪费资源,只要第一次校验通过后,后边就不在进行校验
        jobject context = getApplication(env);
        // 获得Context类
        jclass cls = env->FindClass("android/content/Context");
        // 得到getPackageManager方法的ID
        jmethodID mid = env->GetMethodID(cls, "getPackageManager",
                                         "()Landroid/content/pm/PackageManager;");

        // 获得应用包的管理器
        jobject pm = env->CallObjectMethod(context, mid);

        // 得到getPackageName方法的ID
        mid = env->GetMethodID(cls, "getPackageName", "()Ljava/lang/String;");
        // 获得当前应用包名
        jstring packageName = (jstring) env->CallObjectMethod(context, mid);
        const char *c_pack_name = env->GetStringUTFChars(packageName, NULL);

        // 比较包名,若不一致,直接return包名
        if (strcmp(c_pack_name, PACKAGE_NAME) != 0) {
            return false;
        }
        // 获得PackageManager类
        cls = env->GetObjectClass(pm);
        // 得到getPackageInfo方法的ID
        mid = env->GetMethodID(cls, "getPackageInfo",
                               "(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;");
        // 获得应用包的信息
        jobject packageInfo = env->CallObjectMethod(pm, mid, packageName,
                                                    0x40); //GET_SIGNATURES = 64;
        // 获得PackageInfo 类
        cls = env->GetObjectClass(packageInfo);
        // 获得签名数组属性的ID
        jfieldID fid = env->GetFieldID(cls, "signatures", "[Landroid/content/pm/Signature;");
        // 得到签名数组
        jobjectArray signatures = (jobjectArray) env->GetObjectField(packageInfo, fid);
        // 得到签名
        jobject signature = env->GetObjectArrayElement(signatures, 0);

        // 获得Signature类
        cls = env->GetObjectClass(signature);
        mid = env->GetMethodID(cls, "toByteArray", "()[B");
        // 当前应用签名信息
        jbyteArray signatureByteArray = (jbyteArray) env->CallObjectMethod(signature, mid);
        //转成jstring
        jstring str = toMd5(env, signatureByteArray);
        char *c_msg = (char *) env->GetStringUTFChars(str, 0);
        LOGD("getSignature release sign md5: %s", c_msg);
        isRight = strcmp(c_msg, SIGN_MD5) == 0;
        return isRight;
    }
    return isRight;
}


//有了校验的方法,所以我们要对第3步中,获取密钥和加密方法的进行修改,添加校验的逻辑
extern "C" JNIEXPORT jstring JNICALL Java_com_test_util_HttpKeyUtil_getHttpSecretKey
        (JNIEnv *env, jclass cls, jint index) {
    if (getSignature(env)){//校验通过
      if (随机数条件1) {
        return env->NewStringUTF(KEY1);
      } else if (随机数条件2) {
        return env->NewStringUTF(KEY2);
      } else if (随机数条件3) {
        return env->NewStringUTF(KEY3);
      } else {
        return env->NewStringUTF(UNKNOWN);
      }
    }else {
        return env->NewStringUTF(UNKNOWN);
    }
}

extern "C" JNIEXPORT jstring JNICALL
Java_com_test_util_HttpKeyUtil_getSecretValue
        (JNIEnv *env, jclass cls, jbyteArray jbyteArray1) {
        //加密算法各有不同,这里我就用md5做个示范
    if (getSignature(env)){//校验通过
       return toMd5(env, jbyteArray1);
    }else {
        return env->NewStringUTF(UNKNOWN);
    }
}复制代码

5.总结

以上就是此次事件native的相关代码,至于如何生成so库可以自行百度。从此次事件中需要反思的几点是:

  • 安全性的认识,安全无小事
  • 发布出去的包必须走加固流程,为了防止疏漏,禁止人工打包加固,全部通过脚本实现
  • 服务端增加相关风险的报警机制

相关 [android 数据 思考] 推荐:

Android敏感数据泄露引发的思考

- -
一个平淡的午后,我还悠哉悠哉的敲着代码品着茶. 突然服务端同事告诉我,关注接口正在被机械式调用,怀疑是有人在使用脚本刷接口(目的主要是从平台导流). 不会吧,因为据我所知接口请求是做了加密处理的,除非知道加密的密钥和加密方式,不然是不会调用成功的,一定是你感觉错了. 然而当服务端同事把接口调用日志发给我看时,彻底否定了我的侥幸心理.

Android 数据持久化

- - CSDN博客推荐文章
在Android中,实现数据持久化主要有四种方式:Preferences,文件I/O,SQLite数据库,ContentProvider组件. 在我们 RUI中上述的几种方法都要涉及,其中LauncherProvider.java文件属于第四种,提供对数据库的一些操作,下面将重点介绍使用ContentProvider来实现数据持久化,其它方法将做简要介绍.

Android--用JSON解析数据

- - CSDN博客移动开发推荐文章
gson-1.7.1.jar,Gson在Android3.0以上才能直接使用,在3.0以下想使用可以从外部导入jar包. 下载链接: http://download.csdn.net/detail/zlqqhs/5075995. 新建工程,新建一个libs文件夹,将gson-1.7.1.jar复制到libs文件夹中.

对数据库架构的再思考

- - 人月神话的BLOG
前面在谈PaaS的时候曾经谈到过共享数据库,私有数据库的问题,在这里再谈谈在多业务系统建设过程中的数据架构模式问题. 首先来看下传统的数据交换解决方案如下图:. 业务场景为单独构建的四个业务系统,在四个业务系统中SID数据为需要跨四个应用交互和共享的数据. 传统的做法则是对四个应用存在的SID库数据进行数据集成和交换,则后续的每一个业务系统中都有全部的共享基础数据,任何一个应用的SID库数据需要通过数据交换和集成同步四份.

数据一致性的一些思考

- - 掘金 架构
没有银弹,需要根据自己的业务场景做取舍. 业务量有多少,需要主从读写分离么,需要分库分表么. 是需要多表合并,还是多行合并,还是多库合并. 该如何容灾?更新、删除缓存失败你能不能接受. 如果删除缓存失败,你还允不允许更新数据库. 要根据实际业务场景来定制方案. 大部分业务场景都是读多写少,而且数据库(mysql)写很少看到写挂的,都是读有瓶颈.

PC、iOS、Android等多平台通用性交互设计思考

- - 微博UDC
作为一名普通用户,吐个槽先~. 虽然不是5岁的美国小萝莉,不过我还是受够了各种操作平台的分类,以及浏览一个网站或者使用一款产品要学多个版本的行为. 各种PC版、iPhone版、iPad版(所谓的HD)、Android版… 我想说,版你妹呀…. 针对多平台这一问题,很多网站的解决方法,是为不同的设备提供不同的网页,比如专门提供一个Mobile版本,或者iPhone 、iPad版本.

android service常驻内存的一点思考

- - CSDN博客推荐文章
我们总是不想自己的Android service被系统清理,以前时候大家最常用的办法就是在JNI里面fork出子进程,然后监视 service进程状态,被系统杀死了就重启它.. 我分别在android4.3和android5.0上面测试了LBE的清理内存功能,看看是不是会达到不被清理的目的,发现在这两个版本上还是有一些区别的.

Android内存泄漏思考 - 编程学习网

- -
Android内存泄漏是一个经常要遇到的问题,程序在内存泄漏的时候很容易导致OOM的发生. 那么如何查找内存泄漏和避免内存泄漏就是需要知晓的一个问题,首先我们需要知道一些基础知识. 强引用: 强引用是Java中最普通的引用,随意创建一个对象然后在其他的地方引用一下,就是强引用,强引用的对象Java宁愿OOM也不会回收他.

Android数据库导出工具—ADEL

- - FreebuF.COM
ADEL(Android Data Extractor Lite)这款工具可自动导出Android 2.x移动设备的SQLite数据库,并且释放下载文件中的存储内容. 以下数据库会被ADEL导出 telephone and SIM-card information (e. IMSI and serial number) telephone book and call lists, calendar entries, SMS messages, GPS locations from different sources on the smartphone.

Android数据库升级实例

- - BlogJava-qileilove
  Andoird的SQLiteOpenHelper类中有一个onUpgrade方法. 经过实践,解决了我一连串的疑问:. 帮助文档里说的“数据库升级”是指什么.   你开发了一个程序,当前是1.0版本. 到1.1版本时,你在数据库的某个表中增加了一个字段. 那么软件1.0版本用的数据库在软件1.1版本就要被升级了.