作者:Airsj
链接:https://juejin.im/post/6862732328406351879
事件始末
一个平淡的午后,我还悠哉悠哉的敲着代码品着茶。突然服务端同事告诉我,关注接口正在被机械式调用,怀疑是有人在使用脚本刷接口(目的主要是从平台导流)。
纳尼?不会吧,因为据我所知接口请求是做了加密处理的,除非知道加密的密钥和加密方式,不然是不会调用成功的,一定是你感觉错了。然而当服务端同事把接口调用日志发给我看时,彻底否定了我的侥幸心理。
- 接口调用频率固定为
1s
一次 - 被关注者的
id
每次调用依次加一(目前业务上用户id的生成是按照注册时间依次递增的) - 加密的
密钥
始终使用固定的一个(正常的是在固定的几个密钥中每次会随机使用一个)
综合以上三点就可以断定,肯定是存在刷接口的行为了。
事件分析
既然上述刷接口的行为成立,也就意味着密钥和加密方式被对方知道了,原因无非是以下两点:
- 内部人员泄露
- apk被破解
经过确认基本排除了第一点,那就只剩下apk被破解了,可是apk发布出去的包是进行过加固和混淆处理的,难道对方脱壳了?不管三七二十一,自己先来反编译试试。于是乎从最近发布的版本一个一个去反编译,最后在反编译到较早前的一个版本时发现,保存密钥和加密的工具类居然源码完全暴露了。
炸了锅了,排查了一下这个版本居然未加固过就发布出去了,而且这个加密工具类未被混淆。虽然还不太清楚对方是不是按照这种方式获取的密钥和加密算法,但无疑这是客户端存在的一个安全漏洞。
事件处理
既然已经发现了上述问题,那就要想办法解决。首先不考虑加固,如何尽最大可能保证客户端中的敏感数据不泄露?另一方面即使对方想要破解,也要想办法设障,增大破解难度。想到这里基本就大致确定了一个思路:使用NDK,将敏感数据和加密方式放到native层,因为C 代码编译后生成的so库是一个二进制文件,这无疑会增加破解的难度。利用这个特性,可以将客户端的敏感数据写在C 代码中,从而增强应用的安全性。 说干就干吧!!!
1.首先创建了加密工具类:
代码语言:javascript复制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
代码语言:javascript复制
代码语言:javascript复制#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文件
代码语言:javascript复制#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);
// 在末尾补
*(char_result intArrayLength * 2) = '