如何系统开展Android应用审计测试？

Android应用审计测试不是简单的漏洞扫描，而是一套结合逆向工程、权限模型分析和运行时验证的流程。审计的目标是发现应用在权限声明、组件暴露、数据存储、网络传输和WebView实现等方面是否存在可被攻击者利用的缺陷。本文围绕审计环境搭建、静态代码审计、动态插桩测试和常见漏洞修复展开，给出可操作的命令与脚本示例。

审计测试的准备工作与环境搭建

开展Android应用审计之前，需要准备一套独立的测试环境。最低配置包括JDK 11或更高版本、Android SDK平台工具、以及一台已获取root权限的测试设备或模拟器。root权限对于动态插桩和文件系统遍历至关重要，因为很多敏感数据只能通过root后查看应用私有目录。

常用的逆向与审计工具包括apktool、jadx、Frida和Objection。apktool用于反编译资源文件和Manifest，jadx则可将DEX字节码还原为可读的Java代码。Frida是一个动态插桩框架，能够在运行时Hook任意方法，Objection基于Frida提供了一系列自动化安全扫描命令。安装apktool需要在Linux或macOS下执行以下命令，并将脚本复制到PATH目录。

# 安装apktool
wget https://raw.githubusercontent.com/iBotPeaches/Apktool/master/scripts/linux/apktool
wget https://bitbucket.org/iBotPeaches/apktool/downloads/apktool_2.9.3.jar -O apktool.jar
chmod +x apktool apktool.jar
sudo mv apktool apktool.jar /usr/local/bin/
apktool --version

安装Frida可以通过pip完成，并需要在设备端运行对应版本的frida-server。确保frida-server与主机Frida版本一致，否则会出现连接失败。具体操作是先从GitHub下载frida-server对应Android架构的二进制文件，然后通过adb push到设备并给予执行权限。

# 主机安装Frida
pip install frida-tools
# 查看设备CPU架构
adb shell getprop ro.product.cpu.abi
# 推送frida-server并启动
adb push frida-server /data/local/tmp/
adb shell chmod 755 /data/local/tmp/frida-server
adb shell /data/local/tmp/frida-server &

环境搭建完成后，需要确认设备已开启USB调试并授权。审计过程建议使用专门的测试设备，避免对生产环境造成影响。接下来就可以开始对目标APK进行静态分析。

静态审计的关键方法与工具

静态审计的第一步是获取APK文件并反编译其资源及Manifest。使用apktool可以解包APK，输出目录中包含AndroidManifest.xml、res资源和smali代码。Manifest文件记录了应用声明的权限、注册的四大组件以及组件是否导出。导出的组件（android:exported="true"）是攻击面分析的重点，因为它们可以被其他应用通过Intent调用。

# 反编译APK
apktool d target.apk -o target_decoded
# 查看Manifest文件
cat target_decoded/AndroidManifest.xml

在反编译后的AndroidManifest.xml中，需要特别关注以下标签：<activity>、<service>、<receiver>和<provider>。如果这些标签带有android:exported="true"属性且未设置权限保护，就存在被恶意应用启动或访问的风险。例如一个导出的ContentProvider如果没有正确的读写权限，可能导致数据泄露或目录遍历。

<provider
    android:name=".FileProvider"
    android:authorities="com.example.fileprovider"
    android:exported="true"
    android:grantUriPermissions="true">
</provider>

接下来使用jadx将DEX反编译为Java源码，便于审查业务逻辑。重点关注硬编码密钥、敏感信息写入日志、不安全的文件读写和WebView配置。硬编码的AES密钥或API Token可以直接被提取，攻击者利用这些信息可以伪造请求或解密数据。在代码中搜索关键词如“key”、“secret”、“token”、“password”等可以帮助快速定位。

// 不安全的硬编码密钥示例
private static final String AES_KEY = "1234567890abcdef";
// 敏感信息写入日志
Log.d("DEBUG", "User token: " + token);

静态审计还需要检查应用的数据存储方案。SharedPreferences默认以明文XML文件存储，如果保存了密码或令牌且未加密，攻击者通过root设备可以轻松读取。内部存储文件同样需要加密处理。此外，网络传输配置也要审查，检查是否使用HTTPS及是否实现了证书校验。未校验主机名的HTTPS同样存在中间人攻击风险。

动态审计与运行时分析

动态审计可以在真实运行环境中验证静态分析发现的疑似漏洞，并发现静态代码中难以察觉的运行时行为。Frida是动态插桩的核心工具，它允许测试人员编写JavaScript脚本来Hook任意Java方法，打印参数、修改返回值或绕过SSL证书校验。

以一个实际场景为例，假设我们怀疑应用在登录时使用了不安全的HTTP请求。通过Frida可以Hook OkHttp的Request构建方法，打印出完整的URL和请求体。下面脚本演示了如何Hook okhttp3.Request$Builder类的url方法。

Java.perform(function () {
    var RequestBuilder = Java.use('okhttp3.Request$Builder');
    RequestBuilder.url.overload('java.lang.String').implementation = function (url) {
        console.log('Request URL: ' + url);
        return this.url(url);
    };
});

Objection在Frida之上提供了命令行式的安全扫描能力。它可以快速枚举应用导出的Activity、检测root绕过、执行SSL Pinning绕过等。例如使用objection -g com.example.app explore进入交互模式，然后运行android sslpinning disable即可禁用证书锁定，便于抓包分析明文流量。

# 启动Objection
objection -g com.example.app explore
# 交互模式内输入
android sslpinning disable
android hooking list activities

动态审计还要关注文件系统访问和ContentProvider调用。通过adb shell进入应用沙箱，查看/data/data/包名/目录下的文件权限和内容。如果SharedPreferences文件存储了明文密码，可以在测试设备上直接读取。对于导出的ContentProvider，可以使用adb命令或编写测试应用调用其URI，尝试读取未授权数据。

# 查看应用私有目录
adb shell run-as com.example.app ls -la /data/data/com.example.app/shared_prefs/
# 读取SharedPreferences文件
adb shell run-as com.example.app cat /data/data/com.example.app/shared_prefs/login.xml

常见漏洞的检测与修复建议

Android应用审计中反复出现的高危漏洞类型相对固定，掌握这些漏洞的检测方法和修复思路可以大幅提升审计效率。首先是WebView远程代码执行漏洞，当应用通过addJavascriptInterface向WebView暴露Java对象且未限制加载的URL时，攻击者可以诱导用户打开恶意网页执行任意代码。检测方法是搜索addJavascriptInterface调用并确认是否对输入URL做了白名单校验。修复时应避免在WebView中暴露敏感接口，或使用@JavascriptInterface注解并限制访问来源。

// 修复前：无限制的Javascript接口
webView.addJavascriptInterface(new JSInterface(), "android");
// 修复后：移除接口或增加URL白名单
if (isTrustedUrl(url)) {
    webView.addJavascriptInterface(new SafeJSInterface(), "android");
}

ContentProvider目录遍历漏洞通常源于未对Uri路径进行规范化处理。攻击者可以通过编码路径（如%2e%2e%2f）绕过权限检查，读取任意文件。修复方式是在openFile方法中对用户提供的路径进行严格校验，禁止包含../或使用Uri.decode后再次验证。同时建议设置android:exported="false"或添加android:permission限制访问。

硬编码密钥和敏感信息日志泄露是移动应用中最常见的两类漏洞。硬编码密钥可以通过逆向分析直接提取，导致加密形同虚设。日志泄露则可能被通过adb logcat获取，暴露用户令牌和隐私数据。修复建议是将密钥迁移到Android Keystore系统或使用服务端下发，并在发布版本中关闭调试日志。使用ProGuard或R8混淆虽然不能完全阻止逆向，但可以增加攻击成本，建议作为辅助手段。

整个Android审计测试过程需要将静态分析与动态验证结合，并形成可复用的检查清单。每次审计后应记录发现的漏洞、攻击路径和修复状态，持续跟踪直到闭环。安全测试不是一次性的活动，而应纳入应用开发流程，与CI/CD集成，在每次构建时自动执行静态扫描与关键动态用例，从而降低线上风险。

Android审计安全测试代码审计修改时间：2026-09-19 02:37:58