2、Android网络安全架构：Android网络安全配置、网络安全策略文件、网络安全最佳实践
聊到Android网络安全架构，很多人第一反应就是「哦，那个network_security_config.xml」。没错，这确实是核心。但我想说，如果你只把它当成一个配置文件来用，那就太亏了。
我个人习惯把网络安全架构理解成三层：策略定义层、策略执行层、策略兜底层。说白了，就是先定规矩，再让系统按规矩办事，最后留一手防止规矩被绕过。
2.1 网络安全策略文件：你的第一道防线
从Android 7.0（API 24）开始，Google强制要求所有应用默认只信任系统CA证书。这意味着什么呢？你想想看，以前随便装个用户证书就能抓包的日子，一去不复返了。
嗯，这里要注意：网络安全策略文件是声明式的。你不需要写一行Java代码，只需要在XML里配置好规则，系统就会自动执行。
先看一个最基础的配置示例：
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config cleartextTrafficPermitted="false">
<trust-anchors>
<certificates src="system" />
</trust-anchors>
</base-config>
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">10.0.2.2</domain>
<domain includeSubdomains="true">localhost</domain>
</domain-config>
<debug-overrides>
<trust-anchors>
<certificates src="user" />
</trust-anchors>
</debug-overrides>
</network-security-config>这段配置做了三件事：
- 全局禁止明文流量——所有HTTP请求默认被拦截
- 放行本地调试地址——10.0.2.2和localhost允许HTTP
- Debug模式下信任用户证书——方便抓包调试
2.2 网络安全配置的核心元素
我们来拆解一下网络安全策略文件里的关键元素。说实话，刚开始接触时我也觉得有点绕，但用多了就发现其实很清晰。
| 配置元素 | 作用 | 使用场景 |
|---|---|---|
| <base-config> | 全局默认配置 | 设置所有域名的默认行为 |
| <domain-config> | 特定域名配置 | 为特定域名单独设置规则 |
| <trust-anchors> | 信任锚点配置 | 指定信任哪些CA证书 |
| <debug-overrides> | 调试模式覆盖 | 仅Debug版本生效的配置 |
| <certificates> | 证书来源 | system（系统）/ user（用户）/ 自定义 |
为什么要有这么多层级？说白了，就是为了灵活。你想想看，一个App可能同时连接多个后端服务：
- 主业务API必须走HTTPS，且只信任系统CA
- CDN资源可以放宽一些
- 本地开发环境需要HTTP支持
- 测试环境可能需要自签名证书
这些需求，靠一个base-config是搞不定的。domain-config和debug-overrides就是用来解决这些「例外情况」的。
2.3 证书绑定：从配置到代码的进阶
网络安全策略文件能解决大部分问题，但还不够。为什么？因为CA体系本身就有漏洞——任何CA都可以签发任意域名的证书。如果某个CA被攻破，或者政府要求CA签发伪造证书，你的HTTPS连接就形同虚设。
这时候就需要证书绑定（Certificate Pinning）了。说白了，就是告诉App：「我只认这一个证书，其他的统统滚蛋」。
在Android中实现证书绑定，有两种主流方式：
- 使用OkHttp的CertificatePinner——最推荐的方式
- 自定义X509TrustManager——更底层，更灵活
先看OkHttp的方式：
OkHttpClient client = new OkHttpClient.Builder()
.certificatePinner(new CertificatePinner.Builder()
.add("api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
.add("api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")
.build())
.build();这里有个细节：我建议至少绑定两个证书。一个是当前正在用的，另一个是备份证书。为什么？因为证书会过期。如果你只绑定一个，证书更新那天就是App崩溃之日。
2.4 网络安全最佳实践：我踩过的坑
做了这么多年移动安全，有些坑真的是用血泪换来的。我总结了几条最实用的最佳实践：
2.4.1 永远不要信任用户证书
除非是Debug模式，否则release版本绝对不要加certificates src="user"。用户证书意味着任何安装了抓包工具的人都能解密你的流量。你想想看，这跟明文传输有什么区别？
2.4.2 明文流量要「零容忍」
从Android 9开始，明文流量默认被禁止。但我见过很多App为了兼容旧版本，在base-config里设置了cleartextTrafficPermitted="true"。这等于把系统保护给关了。我的建议是：全局禁止，个别放行。
2.4.3 网络安全策略文件要纳入CI/CD
这个很多人会忽略。网络安全策略文件一旦出错，可能导致整个App的网络功能瘫痪。我建议在CI流水线中加入对network_security_config.xml的校验：
- 检查是否有
cleartextTrafficPermitted="true"的全局配置 - 检查release版本是否包含
debug-overrides - 检查证书指纹是否与预期一致
2.4.4 运行时检测与兜底
配置文件是静态的，但攻击是动态的。我习惯在App启动时做一次运行时检测：
// 运行时检测网络安全策略是否生效
NetworkSecurityPolicy policy = NetworkSecurityPolicy.getInstance();
if (!policy.isCleartextTrafficPermitted()) {
Log.d("Security", "明文流量已被禁止");
}
// 检测是否被Hook或注入
if (detectXposed() || detectFrida()) {
// 触发安全策略，比如退出App或上报
triggerSecurityAlert();
}2.5 总结：安全是一个系统工程
Android网络安全架构不是靠一个配置文件就能搞定的。它需要：
- 声明式配置——network_security_config.xml打好基础
- 代码层加固——证书绑定、运行时检测
- 流程保障——CI/CD校验、证书更新机制
- 兜底策略——Native层保护、反Hook检测
说实话，没有绝对的安全。我们能做的，就是让攻击者觉得「搞这个App太费劲了，换个目标吧」。安全攻防，本质上是一场成本博弈。
嗯，这一章的内容就到这里。记住：网络安全配置不是写完了就完事了，它需要持续维护和更新。证书会过期，域名会变更，攻击手法也在进化。保持警惕，保持更新。
公众号:蓝海资料掘金营，微信deep3321