企业官网建设流程全解析

• 文档
• 教程
• 网络安全

本文围绕 OWASP MASTG 测试用例 MASTG-TEST-0242 展开，讲解如何通过静态与代码审查手段检测 Android 应用的 Network Security Configuration（NSC）中是否对关键第一方域名配置了证书锁定（Certificate Pinning）。读完后，你将掌握一套完整的检测流程：从逆向 APK、提取 AndroidManifest 与 NSC 文件，到枚举<pin-set>、识别第一方域名，再到静态/动态交叉验证，并能准确判定"锁定缺失"与"第三方域名未锁定"之间的边界，避免误报。

一、测试目标与判定原则

MASTG-TEST-0242 针对的是 MASWE-0028（证书锁定缺失/失效）这一弱项，属于静态与代码审查（type: [static, code]）测试。Android 应用通过 NSC 为每个域名声明一个或多个公钥摘要（pin），从而确保应用只与持有特定身份的远端建立连接，抵御中间人（MITM）攻击，详见知识文件 MASTG-KNOW-0015。

该测试的核心判定逻辑可以概括为三点：

1. 只对第一方域名负责：相关域名是开发者掌控的、支撑应用核心或安全敏感功能的远端端点。第三方域名（分析、崩溃上报、广告、社交媒体 SDK 等）即使出现在流量中，也不能仅因其缺少 pin 就上报，判定原则见先决条件 identify-first-party-domains。
2. NSC 未配置或不覆盖相关域名 → 失败：如果应用连接了相关第一方域名，但既没有设置networkSecurityConfig，或者设置了却没有为这些域名启用证书锁定，则测试失败。
3. 其他锁定实现 ≠ 确认缺失：如果为同一域名识别到了其他证书锁定实现（如自定义TrustManager或第三方库），结果应视为"未被 NSC 覆盖"，而非"确认无锁定"。

二、检测流程（Steps 完整解析）

原文档给出的五步流程，对应到仓库中的技术文件如下：

2.1 逆向与提取清单文件

逆向可使用 jadx（CLI 或 GUI）完成，仅提取资源而不反编译全部源码时可用jadx --no-src -d out_dir app.apk。清单文件最终落在out_dir/resources/AndroidManifest.xml（jadx）或output_dir/AndroidManifest.xml（apktool）。不同工具输出格式有差异：jadx 与 apktool 输出标准 XML（属性带android:前缀），而 aapt2 输出的是自定义解码格式（如application-debuggable），详见 MASTG-TECH-0150。

2.2 检查是否声明 networkSecurityConfig

在清单中搜索android:networkSecurityConfig属性：

grep -i "android:networkSecurityConfig" out_dir/resources/AndroidManifest.xml

若<application>标签中存在该属性，则指向一个@xml/<filename>资源引用，其真实文件位于<output_dir>/res/xml/<filename>.xml，映射规则详见 MASTG-KNOW-0014 与 MASTG-TECH-0151。若属性缺失，则应用使用系统默认 NSC（不含任何 pin），测试直接倾向于失败。

NSC 的层级结构为：base-config作用于应用所有连接，domain-config对特定域名覆盖base-config并可承载<pin-set>，详见 MASTG-KNOW-0014。

2.3 提取已配置 pin 的域名

对 NSC 文件使用yq+jq可以结构化提取所有配置了<pin-set>的域名。先转换为 JSON：

yq -p=xml -o=json '.' network_security_config.xml > network_security_config.json

再查询带 pin 的域名：

jq -r ' .["network-security-config"]["domain-config"][] | select(.["pin-set"] != null) | .domain | if type == "object" then .["+content"] else . end ' network_security_config.json

示例输出：

example.com api.example.org

该用法完整继承自 MASTG-TECH-0151，可直接复制到实际分析环境使用。此外也可以用grep -i "pin-set" network_security_config.xml做快速确认。

2.4 枚举应用连接的第一方域名

MASTG-TECH-0022 提供了两条路径：一是用自动化工具（如 semgrep、strings 类工具）枚举二进制中的域名字符串；二是对反编译后的代码做正则匹配。后者能提供上下文——可以看到每个域名在哪个类、哪个方法中使用，这对后续数据流追踪非常关键。

将 2.3 输出的"已 pin 域名集合"与 2.4 的"第一方域名集合"做差集，即可得到"连接了但未配置 pin 的相关第一方域名"。

三、NSC 证书锁定的工作原理与配置示例

理解测试的前提是理解 NSC 的锁定机制。根据 MASTG-KNOW-0015，系统在建立连接时会：

1. 获取并验证对端证书；
2. 提取公钥；
3. 计算公钥摘要（对 X.509 证书的 SubjectPublicKeyInfo 做 SHA-256）；
4. 与本地 pin 集合比对，只要至少一个 pin 匹配即视为有效，连接继续。

仓库中给出的标准配置示例（API 24+）如下：

<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <!-- Use certificate pinning for OWASP website access including sub domains --> <domain includeSubdomains="true">owasp.org</domain> <pin-set expiration="2028-12-31"> <!-- Hash of the public key of the Intermediate CA --> <pin digest="SHA-256">YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=</pin> <!-- Hash of the public key of the Root CA --> <pin digest="SHA-256">Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=</pin> </pin-set> </domain-config> </network-security-config>

配置要点（来自 MASTG-KNOW-0015）：

• 备份 pin：务必为每个 pin-set 提供至少一个备用 pin，避免主证书轮换时连接中断；
• 过期日期：expiration必须设置并按时更新，过期后系统将不再执行 pin 校验，等于自动失效；
• 作用范围：NSC 锁定适用于HttpsURLConnection及依赖它的库、同应用内的WebView请求（除非自定义TrustManager）；native 代码（C/C++/Rust）的网络通信不受 NSC 约束，需另行处理。

需要特别注意的是，NSC 只是证书锁定的其中一种实现方式。MASTG-KNOW-0015 还列举了自定义TrustManager、第三方库（如 OkHttp 的CertificatePinner）、native 代码锁、跨平台框架（Flutter/React Native/Cordova 各有差异）等其他实现。因此本测试的结论边界是**"NSC 中是否存在锁定"**，而不是"应用是否具备任何锁定能力"。

四、进一步验证（Further Validation Required）

原文档明确指出，在上报"pin 缺失"之前必须确认应用确实会建立到相关第一方域名的连接，且给出了两种验证方式：

4.1 静态验证：数据流追踪

使用 MASTG-TECH-0023（审查反编译后的 Java 代码）从硬编码 URL 出发，追踪引用该 URL 的代码到发起网络连接的位置。具体做法是在反编译代码（如 jadx GUI）中 Ctrl+click 跳转到 URL 字符串的使用点，沿着调用链定位到HttpsURLConnection、OkHttpRequest、WebView.loadUrl等网络发起处，确认该域名在运行时真实被访问。

4.2 动态验证：流量抓取与 API 挂钩

• 使用拦截代理抓取并分析网络流量（对应 MASTG-TECH-0011 一类的动态流量分析），观察应用实际连接了哪些域名；
• 或者在运行时挂钩（hook）相关网络 API（如HttpURLConnection.connect、OkHttpClient.newCall），日志记录应用连接的域名。

4.3 归属判定

identify-first-party-domains 强调：第一方归属信息通常无法仅从应用二进制推断，往往需要与开发团队沟通或参考架构/基础设施文档。若此类信息不可得，则基于应用品牌、包名与观察到的流量推断可能的第一方域名，并文档化所做假设。典型第一方端点包括：认证/身份端点（登录、token 签发、会话管理）、账户与用户内容 API、承载核心功能的应用后端 API。

五、评估结论的正确表述

综合以上，测试结果的判定应遵循原文档 MASTG-TEST-0242 的 Evaluation 部分：

• 失败条件：应用连接了相关第一方域名，但（a）未设置networkSecurityConfig，或（b）设置了但未为这些域名配置<pin-set>。
• 不应判失败：仅因为无关第三方域名未 pin。
• 需标注为"未覆盖"：为同一域名识别到自定义TrustManager或第三方库锁定时，应表述为"未被 NSC 覆盖"，而非"确认无锁定"。

六、相关资源索引

• 文档
• 教程
• 网络安全