企业官网建设流程全解析

• 文档
• 教程
• 网络安全

导读

本文基于 OWASP Mobile Application Security Testing Guide（MASTG）中的测试用例 MASTG-TEST-0343，系统讲解如何在 iOS 应用中检测URLSession的弱 TLS 协议配置。你将掌握URLSessionConfiguration两个 TLS 版本属性的判定标准、它们与 App Transport Security（ATS）的相互作用关系，以及从 IPA 包提取二进制、静态分析到人工复核的完整取证流程，最终能够独立完成 MASVS-NETWORK 类别下该弱点的评估与报告撰写。

该测试用例归属于MASWE-0026弱点、关联最佳实践 MASTG-BEST-0042，并依赖 MASTG-KNOW-0071（ATS 机制）与 MASTG-KNOW-0073（iOS 网络 API 分层）两篇知识文档。

测试目标：URLSession 的 TLS 最小版本配置

在 iOS 中，URLSession是 URL Loading System 中最常用的高层网络接口。通过URLSessionConfiguration，应用可以为单个URLSession实例定制 TLS 行为。其中控制会话 TLS 版本下限的属性有两个：

• tlsMinimumSupportedProtocolVersion：现代属性，接受tls_protocol_version_t枚举值；
• tlsMinimumSupportedProtocol：已废弃的旧属性，接受SSLProtocol枚举值（如kTLSProtocol1）。

注意：废弃属性tlsMinimumSupportedProtocol仍可被使用（例如旧代码或第三方库），使用它设置不安全的 TLS 最低版本同样会削弱该会话的 TLS 保护，因此它同样属于本测试的检测范围。

根据 MASTG-KNOW-0073，URLSessionConfiguration还暴露了对应的上限属性tlsMaximumSupportedProtocolVersion（及其废弃前身tlsMaximumSupportedProtocol）。虽然本测试主要关注最小版本，但在实际审计中，若发现应用同时压低了最小版本又调低了最大版本，应一并记录。

为什么 TLS 1.0 / 1.1 是弱配置

将tlsMinimumSupportedProtocolVersion设为.TLSv10（tls_protocol_version_TLSv10，值0x0301）或.TLSv11（tls_protocol_version_TLSv11，值0x0302）属于不良实践，必须标记为失败。TLS 1.0 与 TLS 1.1 均已废弃多年，存在已知的协议级弱点（例如 TLS 1.0 对 BEAST 类攻击的敏感性、较弱的密码套件组合等），不应用于生产环境。

从 MASTG-BEST-0042 的角度看，正确做法是：不要将最小版本显式设置为 TLS 1.0 或 1.1，优先保留默认值——默认值会继承 ATS 的最小版本要求（TLS 1.2 及以上）。此外，自 iOS 26 起，URLSession与 Network.framework 已强制要求最低 TLS 1.2，系统层面不再接受任何允许 TLS 1.0/1.1 的豁免配置，这进一步说明该弱点在当代系统上的风险收益完全失衡。

关键前提：URLSession 不绕过 ATS

本测试最容易被误解的一点是：与 Network.framework 不同，URLSession不会绕过 ATS。

ATS（App Transport Security）自 iOS 9 起由操作系统强制实施，作用于 URL Loading System 发起的连接，其默认要求包括：

• TLS 版本 1.2 或更高；
• 数据加密使用 AES-128 或 AES-256；
• 证书签名使用 RSA（≥2048 位）或 ECC（≥256 位）密钥；
• 证书指纹使用 SHA-256 或更高；
• 通过 ECDHE 密钥交换支持完美前向保密（PFS）。

因此，即使应用在代码中将tlsMinimumSupportedProtocolVersion设为 TLS 1.0，ATS 依然会对该连接执行自己的最小 TLS 版本要求。除非Info.plist中存在匹配的 ATS 豁免（NSExceptionMinimumTLSVersion），否则连接在运行时仍会被 ATS 拦截。这正是 MASTG-KNOW-0071 所强调的："代码中设置的值与 ATS 独立评估，ATS 在代码配置之上叠加自身的 TLS 下限"。

与之形成鲜明对比的是 Network.framework：ATS 并不适用于该低层框架，任何在代码中配置的弱 TLS 设置（如最低 TLS 1.0）会直接生效，没有 ATS 这道安全网。这解释了为什么本测试（针对 URLSession）必须结合 ATS 配置综合评估，而不能只看代码。

检测步骤

本测试属于[static, code, manual]类型，即静态 + 代码级 + 人工确认的混合型测试，包含三个标准步骤。

步骤一：从应用包提取二进制（MASTG-TECH-0058）

使用技术文档 MASTG-TECH-0058 从 IPA 包中提取相关二进制。核心操作是解压 IPA：

unzip AppName.ipa

解压后得到Payload/目录，其中包含 Application Bundle（.app）。对 TLS 配置审计而言，最重要的产物是：

• 应用二进制：位于Payload/AppName.app/AppName（与 bundle 同名、无.app后缀），包含应用的主要代码，即本测试需要静态分析的对象的 Swift/Objective-C 实现；
• Info.plist：包含 ATS 配置（NSAppTransportSecurity）等关键信息，用于后续结合评估；
• Frameworks/：原生动态库与 framework，第三方网络库的 TLS 配置代码可能在这里，也值得检查。

该技术文档还给出了查看Info.plist的实用命令（Linux 环境需先安装libplist-utils）：

apt install libplist-utils plistutil -i Info.plist -o Info_xml.plist

步骤二：在二进制中定位相关 API（MASTG-TECH-0066）

使用技术文档 MASTG-TECH-0066 在应用二进制中查找与 TLS 版本配置相关的 API。该文档推荐使用 radare2（r2）进行静态分析，以下是可直接套用的核心命令流程：

列出并过滤函数——URLSession相关的符号通常在sym.imp.导入符号区，可用afl配合~过滤：

afl~tlsMinimumSupportedProtocol

检查动态解析的函数——某些函数不会出现在afl列表中（如通过dlopen/KVC 动态解析），此时改用 flags 与字符串搜索：

f~tlsMinimumSupportedProtocol iz~tlsMinimumSupportedProtocol

追踪交叉引用（Xrefs）——定位到目标符号地址后，用axt找出其被调用的位置，判断 TLS 配置是在哪段业务代码中设置的：

axt @ 0x1000078ac

也可以使用axg反向绘制调用图，理清配置代码的完整调用链。

反汇编确认——用pdf反汇编目标函数、pd查看指定地址附近的指令，确认实际设置的枚举常量值：

pdf @ <function_address> pd 5 @ 0x1000048c4

如果应用使用 Objective-C，还需留意_objc_msgSend调用链中的 selector 字符串（如setTLSMinimumSupportedProtocolVersion:）；若使用 Swift，则关注tlsMinimumSupportedProtocolVersion属性写入点的符号。

步骤三：人工复核代码位置（MASTG-TECH-0076）

静态工具命中后，使用技术文档 MASTG-TECH-0076 对每个报告出的代码位置进行人工复核，以确定被设置的 TLS 版本值。该文档强调人工分析需要系统性方法：先理解应用的目标与行为，再检查二进制中的字符串，按名称定位相关函数与类，最后从入口点沿调用链逐段确认。

针对本测试，复核重点是确认代码中写入的常量值——是tls_protocol_version_TLSv10/TLSv11这样的弱值，还是TLSv12/TLSv13的安全值。同时判断该配置是否由第三方库引入（可通过Frameworks/中的库定位），以及是否存在条件分支导致不同路径设置不同版本。

观察输出（Observation）

测试步骤完成后，输出应包含所有配置了 TLS 协议版本的URLSessionConfigurationAPI 调用（如果存在）。记录内容包括：

• 命中位置（二进制中的地址、所属函数/类/库）；
• 被设置的属性名（tlsMinimumSupportedProtocolVersion或废弃的tlsMinimumSupportedProtocol）；
• 设置的具体 TLS 版本常量及对应的十六进制值。

若应用未进行任何显式 TLS 版本配置（保留默认值），观察输出应如实说明"未发现相关 API 调用"，此时测试自然通过。

判定标准（Evaluation）

测试用例在以下任一条件下判定失败：

1. 应用将tlsMinimumSupportedProtocolVersion设置为tls_protocol_version_TLSv10（值0x0301）或tls_protocol_version_TLSv11（值0x0302）；
2. 应用将已废弃的tlsMinimumSupportedProtocol设置为对应 TLS 1.0（kTLSProtocol1）或 TLS 1.1（kTLSProtocol11）的值。

判定时需特别注意两点：

• 区分"配置了弱值"与"配置了安全值"：显式设置为 TLSv12/TLSv13 不构成失败，属于合理的显式加固；
• 区分"代码配置"与"ATS 豁免"：代码中的弱配置由本测试（MASTG-TEST-0343）负责判定；Info.plist中通过NSExceptionMinimumTLSVersion等键弱化 ATS 的配置，则由姊妹测试用例 MASTG-TEST-0342 负责判定。

进一步验证（Further Validation Required）

当静态分析命中可疑代码位置后，还需要结合 ATS 配置进行运行时语义层面的进一步验证。原文档在 ATS 交互上给出了重要提示：

ATS 可能仍会对使用 URL Loading System 的连接强制执行最小 TLS 版本要求，具体取决于Info.plist中的 ATS 配置。然而，如果应用还配置了宽泛的 ATS 豁免（参见 MASTG-TEST-0342），则这些域名的有效 TLS 下限可能低于预期。

也就是说，判定不能停留在"代码里写了 TLS 1.0"这一层，而应回答"该连接实际协商到的最低 TLS 版本是多少"。以下几种组合需要逐一区分：

因此，评估报告的最终结论必须综合 MASTG-TEST-0343（代码配置）与 MASTG-TEST-0342（ATS 配置）两份测试的结果。若代码弱配置与 ATS 宽泛豁免同时存在，构成"纵深防御被双重击穿"的高风险场景，应在报告中突出强调。

与 ATS 配置测试（MASTG-TEST-0342）的协同

为了完整评估 MASWE-0026，应将本测试与 MASTG-TEST-0342 配套执行。MASTG-TEST-0342 关注Info.plist中NSAppTransportSecurity下的三类弱配置：

• NSAllowsArbitraryLoads = true（全局禁用 ATS，允许明文 HTTP）；
• 任一域名/IP 设置NSExceptionMinimumTLSVersion = "TLSv1.0"或"TLSv1.1"；
• 任一域名/IP 设置NSExceptionRequiresForwardSecrecy = false/NO/0（关闭 PFS 要求）。

两份测试的覆盖关系可以概括为：MASTG-TEST-0343 管"代码层面"的 TLS 下限，MASTG-TEST-0342 管"配置层面"的 ATS 豁免。二者结合才能回答"应用对外网络连接的有效安全强度"这一完整问题。注意，ATS 例外中存在早期NSTemporaryException...前缀的废弃键（见 MASTG-KNOW-0071），审计旧应用时也应一并检查。

修复建议

依据 MASTG-BEST-0042，修复方向按优先级排列：

1. 删除弱配置，回归默认值：移除对tlsMinimumSupportedProtocolVersion/tlsMinimumSupportedProtocol的 TLS 1.0/1.1 显式赋值，让会话继承 ATS 的 TLS 1.2 默认下限；
2. 优先修复服务端：如果弱配置是为了兼容旧服务器，应联系服务提供商升级 TLS 版本，而非在客户端持续妥协；任何临时豁免都应尽快移除；
3. 必要时使用窄范围豁免：若豁免不可避免，仅针对具体域名配置、避免NSIncludesSubdomains = true、绝不开全局NSAllowsArbitraryLoads，并为 App Store 审核准备正当性说明（Apple 自 2017 年 1 月 1 日起要求对相关 ATS 例外提供 justification）；
4. 统一使用 URL Loading System：应用层 HTTPS 请求应优先走URLSession等高层 API 以自动获得 ATS 保护；若必须使用 Network.framework / CFNetwork / BSD sockets，则必须在代码中显式配置并强制强 TLS 设置（详见 MASTG-BEST-0043 相关指引，以及 MASTG-KNOW-0073 中sec_protocol_options_set_min_tls_protocol_version等函数的使用方式）。

适用范围与注意事项

• 本测试面向使用URL Loading System（URLSession）的 iOS 应用；使用 Network.framework、CFNetwork 或 BSD sockets 的 TLS 配置不在此测试覆盖范围内（ATS 不适用于这些路径，需按低层 API 场景另行评估）；
• 代码中的弱 TLS 配置本身不会绕过 ATS，判定失败与否取决于有效 TLS 下限，因此务必结合 MASTG-TEST-0342 的 ATS 配置评估；
• 自iOS 26 / macOS Tahoe 26起，系统强制最低 TLS 1.2，TLS 1.0/1.1 连接在操作系统层面直接失败，旧的豁免配置不再被接受——验证面向旧 TLS 版本的配置时，建议在真实 iOS 设备而非模拟器上进行（详见 MASTG-KNOW-0071 的运行时验证章节）；
• 本测试为manual类型，静态工具的命中结果必须经过人工反汇编复核确认，避免将符号引用、废弃代码或动态解析误报为实际生效的配置。

参考文件索引

• 测试用例定义：MASTG-TEST-0343
• 姊妹测试（ATS 配置）：MASTG-TEST-0342
• 技术文档（二进制提取）：MASTG-TECH-0058
• 技术文档（静态分析）：MASTG-TECH-0066
• 技术文档（人工复核）：MASTG-TECH-0076
• 知识文档（ATS）：MASTG-KNOW-0071
• 知识文档（网络 API 分层）：MASTG-KNOW-0073
• 最佳实践（强 TLS 配置）：MASTG-BEST-0042

• 文档
• 教程
• 网络安全