企业官网建设流程全解析

• 文档
• 教程
• 网络安全

本文基于 OWASP MASTG（Mobile Application Security Testing Guide）测试用例 MASTG-TEST-0224，讲解如何检测 Android 应用是否仅启用了已不安全的 v1（JAR）签名方案。通过minSdkVersion与签名方案的双重判定，你可以识别出容易被 Janus 漏洞（CVE-2017-13156）一类攻击篡改的应用，并掌握apksigner、jadx/apktool等工具的完整实操流程，最终给出符合 MASTG-BEST-0006 最佳实践的签名配置修复方案。

测试目标：为什么"仅 v1 签名"是一个安全问题

该测试对应 MASTG 测试项 MASTG-TEST-0224，元数据中声明了如下关键信息：

• 平台：android
• 类型：[static, code]（静态/代码分析类测试，无需动态调试）
• 关联弱点：MASWE-0056
• 关联最佳实践：MASTG-BEST-0006
• 关联知识：MASTG-KNOW-0003

不采用较新的 APK 签名方案，意味着应用缺少更强签名机制提供的完整性保护。v1 签名方案（JAR 签名）存在已知缺陷：它不覆盖 APK 的所有部分，攻击者有可能在不使签名失效的情况下修改 APK 的某些部分——这正是 "Janus" 漏洞（CVE-2017-13156）利用的原理。因此，仅依赖 v1 签名会显著提高应用被篡改的风险。

各签名方案的安全定位

结合 Android 平台概述 中"APK Signing Schemes"一节的说明，Android 支持的签名方案可归纳如下：

其中 v3 方案的 proof-of-rotation 结构是一个单链表：每个节点包含此前版本应用所使用的签名证书，旧证书对新证书链进行签名，从而在密钥泄露更换后仍能保持向后兼容与信任。

需要注意：旧平台会忽略 v2/v3 签名、只校验 v1，因此 APK 通常用多种方案同时签名以兼顾新旧设备。而知识条目 MASTG-KNOW-0003 进一步强调：对每一种签名方案，发布构建都应同时用其所有前代方案签名，这是兼容性的基础——但该测试判定的是"仅 v1 生效"这一更糟的情况。

操作步骤：三步完成签名方案审计

MASTG-TEST-0224 的标准步骤引用了三个 MASTG 技术（Technique），下面逐一展开，并给出可直接执行的命令。

步骤 1：获取 AndroidManifest.xml（MASTG-TECH-0117）

参见 MASTG-TECH-0117。AndroidManifest 以二进制 XML 格式存储，不能直接解包查看，必须解码：

• 使用 jadx（MASTG-TOOL-0018）：jadx --no-src -d out_dir app.apk，输出到out_dir/resources/AndroidManifest.xml。jadx 会保留<uses-sdk>元素，直接包含minSdkVersion。
• 使用 apktool（MASTG-TOOL-0011）：apktool d -s -f -o output_dir app.apk。注意 apktool 解码后的 AndroidManifest.xml 中没有<uses-sdk>元素，它被移到了apktool.yml：

sdkInfo: minSdkVersion: 29 targetSdkVersion: 35

• 使用 aapt2（MASTG-TOOL-0124）：aapt2 d badging app.apk，输出非 XML 格式，可直接看到sdkVersion:'29'一行。

步骤 2：读取 minSdkVersion（MASTG-TECH-0150）

参见 MASTG-TECH-0150。从提取出的 AndroidManifest.xml 中定位minSdkVersion。不同工具的输出格式不同：jadx/apktool 输出标准 XML（属性带android:命名空间前缀），aapt2 输出自定义解码格式。可用的检索命令：

# jadx 输出的标准 XML grep -i "minSdkVersion" out_dir/resources/AndroidManifest.xml # apktool 场景：值在 apktool.yml 中 grep -i "minSdkVersion" output_dir/apktool.yml # aapt2 场景 aapt2 d badging app.apk | grep -i "sdkVersion"

步骤 3：列出所有启用的签名方案（MASTG-TECH-0116）

参见 MASTG-TECH-0116，使用 apksigner（MASTG-TOOL-0123）验证签名：

$ apksigner verify --verbose example.apk Verifies Verified using v1 scheme (JAR signing): false Verified using v2 scheme (APK Signature Scheme v2): true Verified using v3 scheme (APK Signature Scheme v3): true Verified using v3.1 scheme (APK Signature Scheme v3.1): false Verified using v4 scheme (APK Signature Scheme v4): false Verified for SourceStamp: false Number of signers: 1

若需进一步核对签名证书与密钥信息（用于报告溯源），可追加--print-certs：

$ apksigner verify --print-certs --verbose example.apk Signer #1 certificate DN: CN=Example Developers, OU=Android, O=Example Signer #1 certificate SHA-256 digest: 1fc4de52d0daa33a9c0e3d67217a77c895b46266ef020fad0d48216a6ad6cb70 Signer #1 key algorithm: RSA Signer #1 key size (bits): 2048

观察与判定：什么样的结果算测试失败

观察（Observation）

测试的输出应包含两部分：

1. minSdkVersion属性值；
2. 各签名方案的启用状态，例如Verified using v3 scheme (APK Signature Scheme v3): true。

判定规则（Evaluation）

当minSdkVersion属性为 24 及以上、且只有 v1 签名方案启用时，测试用例判定为失败。

这一判定逻辑是合理的：minSdkVersion >= 24意味着应用可以安装在 Android 7.0 及以上设备上，而这些设备完全支持 v2 方案（对整包签名、防 Janus 类攻击），此时却只提供了 v1 签名，等于主动放弃了平台已提供的更强完整性保护。反之，若minSdkVersion低于 24，v1 是兼容旧设备的必要组成部分（通常需与 v2 并存），此时"仅 v1"的风险评估需结合发布渠道与目标用户群综合判断——这正是该测试用例把 minSdkVersion 作为前置条件的意义所在。

修复建议：启用 v2/v3（可选 v4）签名方案

遵循最佳实践 MASTG-BEST-0006："确保应用至少使用 v2 或 v3 APK 签名方案签名，以获得覆盖整个 APK 的完整性检查并防篡改；推荐启用 v3，它还支持密钥轮换；可选地在 Android 11 及以上设备上加入 v4 以加快增量更新，但 v4 单独不提供安全保护，必须与 v2 或 v3 一起使用。"

签名配置可通过 Android Studio 或build.gradle/build.gradle.kts中的signingConfigs段管理。同时启用 v3 与 v4 方案的配置示例（摘自 MASTG-BEST-0006 原文）：

// build.gradle android { ... signingConfigs { config { ... enableV3Signing true enableV4Signing true } } }

修复后重新构建 APK，再用apksigner verify --verbose复核，确认Verified using v2 scheme或Verified using v3 scheme为true，即可使 MASTG-TEST-0224 转为通过。

小结与延伸阅读

• 本文测试项定义：tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0224.md
• 同弱点（MASWE-0056）的姊妹测试：MASTG-TEST-0225 也属于 Android 签名相关审计范畴，可与本项搭配使用形成完整的签名方案检查。
• 签名机制背景：Document/0x05a-Platform-Overview.md 的 "Signing Process" 与 "APK Signing Schemes" 小节（含 v2/v3 校验流程插图）；
• 知识条目：knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0003.md（App Signing 概述与"应同时用前代方案签名"的兼容性原则）。

整体工作流可概括为一句话：用 TECH-0117/0150 读出 minSdkVersion，用 TECH-0116（apksigner）读出签名方案集合，若 minSdkVersion ≥ 24 且仅 v1 为 true，则判定失败并按 MASTG-BEST-0006 开启 v3（及可选 v4）签名重新发布。

• 文档
• 教程
• 网络安全