企业官网建设流程全解析

• 文档
• 教程
• 网络安全

导读

本文围绕 OWASP Mobile Application Security Testing Guide（MASTG）最佳实践条目 MASTG-BEST-0068（Secure Data Sharing Between App Extensions and Containing Apps），系统讲解 iOS 中宿主应用与 App 扩展（Widget、Share Extension、Notification Content Extension 等）通过 App Group 共享数据时的安全设计原则。读完本文，你将掌握三条可落地的防护策略：用共享 Keychain 存放机密、为共享容器中的敏感文件启用 Data Protection 加密、以及最小化共享数据面，从而避免因 App Group 容器"组内成员无逐项访问控制"的特性导致敏感信息泄露。

App Group 共享容器的安全边界：先认清威胁模型

在讨论如何安全共享之前，必须理解底层机制的真实边界。根据 MASTG 的 IPC 知识条目（MASTG-KNOW-0078），iOS 并不提供第三方应用之间通用的直接通信机制，应用与扩展之间的受控交互（App Extensions，即 MASTG-KNOW-0082）属于"受 Entitlement 约束的通道"——扩展与其宿主应用主要通过 App Group 共享数据。

App Group（详见 MASTG-KNOW-0125）是一个基于 Entitlement 的机制，允许来自同一开发者团队的多个应用与扩展共享一个公共文件容器、共享偏好设置（UserDefaults）或 SQLite 数据库等文件。其核心安全属性有两个：

1. 组内无逐项访问控制：所有加入同一 App Group 的应用和扩展，对共享容器内的每个文件/偏好项都拥有同等读写权限。任何成员都可以读取或修改组内数据。
2. 不提供额外加密层：App Group 不增加任何额外加密；共享容器中的文件只依赖标准 iOS 文件系统保护与每个文件自身的 Data Protection 类。

用一句话概括 MASTG-BEST-0068 的结论：共享通道本身不做权限隔离，安全必须靠"选对通道 + 自己加密/加锁 + 少放数据"来实现。

从源码结构看，MASTG 对这条最佳实践的约束在测试侧有对应验证：MASTG-TEST-0299（Data Protection Classes for Files in Private Storage）明确把 App Group 共享容器（/private/var/mobile/Containers/Shared/AppGroup/<UUID>/）与应用私有沙盒目录（/var/mobile/Containers/Data/Application/<UUID>/）并列检查——凡是包含敏感数据的文件，其 Data Protection 类被设置为NSFileProtectionNone即判定测试失败。这印证了"共享容器与私有存储适用同一套加密要求"的立场。

策略一：机密数据优先放入共享 Keychain

当应用与扩展需要共享凭据、令牌、密钥这类高敏数据时，MASTG-BEST-0068 给出的第一原则是：不要放进共享UserDefaults或共享文件容器，而是使用共享 Keychain Access Group（即keychain-access-groupsentitlement）。理由是 Keychain 提供专门、受访问控制保护的密钥存储，并带有独立的 accessibility class（可访问性级别）。

声明共享访问组

根据 MASTG-KNOW-0126，应用通过keychain-access-groupsentitlement 声明其键区访问组，该 entitlement 是一个数组，每一项以应用的 App ID 前缀（通常是 Team ID）开头，例如TeamID.com.example.shared。Xcode 默认会自动添加应用的默认访问组（通常是TeamID.bundleID），额外的共享组需要通过 Keychain Sharing capability 显式声明。

写入共享访问组

存储条目时，在查询字典中加入kSecAttrAccessGroup键即可把条目写入指定共享组（宿主应用与扩展使用同一组 ID 即可互相访问）：

let query: [String: Any] = [ kSecClass as String: kSecClassGenericPassword, kSecAttrAccessGroup as String: "TeamID.com.example.shared", kSecAttrAccount as String: "username", kSecValueData as String: passwordData ] SecItemAdd(query as CFDictionary, nil)

注意：省略kSecAttrAccessGroup时条目会落入应用默认访问组，扩展将无法读取。同时，共享 Keychain 条目同样受 Keychain 自身的 Data Protection 类（kSecAttrAccessible*）保护，与访问组无关。

设置合适的可访问性级别

MASTG-BEST-0068 特别建议为共享条目设置合适的安全属性，例如kSecAttrAccessibleWhenUnlockedThisDeviceOnly——设备解锁时可访问，且不会随备份迁移到其他设备。在 iOS 上这通常比默认选项更严格，尤其适合存放仅当前设备需要的刷新令牌或会话密钥：

let query: [String: Any] = [ kSecClass as String: kSecClassGenericPassword, kSecAttrAccessGroup as String: "TeamID.com.example.shared", kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly, kSecAttrAccount as String: "sessionToken", kSecValueData as String: tokenData ] SecItemAdd(query as CFDictionary, nil)

选择可访问性级别的实践要点：

• WhenUnlocked*系列：设备锁定时不可读，适合绝大多数凭据类数据；
• AfterFirstUnlock*系列：设备首次解锁后持续可读，适合后台扩展（如 Widget 刷新、通知扩展）需要在锁屏后读取的场景；
• *ThisDeviceOnly后缀：限制条目不随 iCloud/备份迁移，防跨设备泄露；
• 应避免使用宽松级别存放共享机密，并在创建条目时一次性指定，因为访问组在条目创建时确定。

策略二：必须放共享容器的敏感文件，启用 Data Protection

并非所有共享数据都适合进 Keychain（例如扩展需要的大体积文件、SQLite 库、缓存）。当敏感数据必须存放在共享文件容器中时，MASTG-BEST-0068 要求为文件应用 Data Protection，使设备锁定时内容保持加密。

写入时直接指定保护类

最简洁的做法是在写入时直接指定.completeFileProtection，对应NSFileProtectionComplete类：

try data.write(to: sharedContainerURL, options: .completeFileProtection)

获取共享容器 URL

共享容器路径通过containerURL(forSecurityApplicationGroupIdentifier:)获取，组 ID 格式为group.<reverse-DNS-string>（例如group.com.example.myapp），并绑定开发者团队：

let sharedContainerURL = FileManager.default .containerURL(forSecurityApplicationGroupIdentifier: "group.com.example.myapp")!

如果使用共享偏好设置而非文件，注意UserDefaults(suiteName: "group.com.example.myapp")写入的数据同样位于共享容器，不会自动获得 Data Protection——这正是不建议用共享 UserDefaults 存机密的原因之一。

保护类覆盖所有共享存储

MASTG-BEST-0068 强调：这一要求适用于所有共享存储，与应用自身私有存储的要求一致（参见 @MASTG-TEST-0299，即 MASTG-TEST-0299）。实际测试时，动态取证步骤会同时检索私有沙盒与 App Group 共享容器中每个文件的数据保护类：

1. 通过 MASTG-TECH-0056 安装应用；
2. 全面触发应用流程（认证、资料加载、消息收发、缓存、离线使用、加解密操作）并尽可能录入敏感数据；
3. 通过 MASTG-TECH-0059 检索两棵目录树下的文件及保护类。

判定标准：包含敏感数据的文件若保护类为NSFileProtectionNone，即未通过。这也意味着，如果你在写入共享容器时省略保护类参数，文件默认继承容器的宽松保护，极有可能在锁屏状态下被读出。

补充：并发读写场景

如果多个进程（主应用与多个扩展）同时读写共享容器中的同一文件，MASTG 的 IPC 知识（MASTG-KNOW-0125）建议配合 file coordination API（MASTG-KNOW-0127）协调并发访问。文件协调本身不是数据交换通道，但它能避免共享文件在并发场景下的损坏与竞态——这是"安全共享"在正确性维度上的另一半。

策略三：最小化共享面（Minimize What You Share）

第三条原则与数据保护同等重要：把共享容器限制在扩展真正需要的数据上。具体做法：

• 避免整体数据集进共享容器：如果扩展只需要某个子集（例如 Widget 只需要最近三条状态），就不要把完整数据库或全部记录放进 App Group；
• 避免把密钥/完整凭据放进共享文件：这类数据应走策略一的 Keychain；
• 按需授予 App Group：只为每个扩展授予其功能所需的 App Group 标识符，而不是给所有扩展统一开全部组。从 MASTG-KNOW-0125 的约束可知，任何组内成员都可读改共享数据，因此数据面越小，攻击面越小；额外的访问控制只能靠应用层逻辑自行实现，而不能依赖容器本身。

决策速查：三类数据该走哪条通道

小结

App Group 是一个强大但"无内部隔离"的共享通道：组内任何成员都能读写共享容器中的全部内容，且容器不提供额外加密。因此 MASTG-BEST-0068 的安全模型可以浓缩为三条可执行规则：

1. 机密走 Keychain：通过keychain-access-groups共享，并配合kSecAttrAccessibleWhenUnlockedThisDeviceOnly等严格可访问性级别；
2. 文件走 Data Protection：共享容器中的敏感文件一律以.completeFileProtection写入，与私有沙盒同等对待（MASTG-TEST-0299 会验证这一点）；
3. 最小化共享面：只共享扩展真正需要的子集，只授予功能必需的 App Group 标识符。

这三条原则的组合，使宿主应用与扩展之间既能保持功能所需的实时数据互通，又不会把 App Group 的"组内无差别读写"缺陷放大为数据泄露入口。在 MASTG 的测试框架中，它们分别由 Keychain 访问组知识（MASTG-KNOW-0126）、App Group 知识（MASTG-KNOW-0125）以及 Data Protection 测试（MASTG-TEST-0299）提供闭环验证，可作为你编写 iOS 应用安全设计与测试用例时的直接参考。

• 文档
• 教程
• 网络安全