企业官网建设流程全解析

• 文档
• 教程
• 网络安全

本指南以 OWASP Mobile Application Security Testing Guide（MASTG）知识库条目 MASTG-KNOW-0128 为主体，系统讲解 iOS 平台上基于 Bonjour 的零配置局域网服务发现机制：涵盖其 mDNS/DNS-SD 底层原理、两代 API（Foundation 与 Network framework）的选型、iOS 14 起的本地网络隐私声明（NSLocalNetworkUsageDescription/NSBonjourServices）配置，以及服务发现之后必须补齐的传输安全与对端认证责任。读者在完成本篇后，将能够在 MASTG 测试流程中准确识别 App 的 Bonjour 使用面、核查其Info.plist隐私声明是否合规，并针对该 IPC 通道制定完整的静态与动态测试方案。

Bonjour 是什么：Apple 的零配置网络实现

Bonjour 是 Apple 基于multicast DNS（mDNS）与DNS Service Discovery（DNS-SD）实现的零配置网络（zero-configuration networking）方案。它允许 App 在局域网内广播（advertise）和发现（discover）服务，无需手动配置 IP、端口或依赖集中式目录服务器（如企业级 DNS 服务器），这与传统依赖 DHCP/DNS 基础设施的服务发现模式有本质区别：

• mDNS：使用224.0.0.251（IPv4）与FF02::FB（IPv6）组播地址在本地链路范围内解析主机名.local形式的名称，无需配置 DNS 服务器；
• DNS-SD：基于现有 DNS 记录类型（PTR、SRV、TXT）描述服务的实例、位置与附加属性，使"发现"这一行为标准化。

在 MASTG 的 iOS 平台分类中，Bonjour 被归类为基于网络的 IPC 通道（Network-based Channel）：它只负责服务发现，真正的数据交换发生在发现之后建立起来的网络连接上（见 MASTG-KNOW-0078）。理解这一点是后续安全分析的前提——发现机制本身不携带业务数据，也不提供任何传输保护。

App Store 应用的典型使用场景

App Store 上架的 App 可以使用 Bonjour 发现并连接同一局域网内的其他设备与服务，包括其他 iOS 设备、Mac、智能家居配件以及第三方硬件。MASTG 文档给出的常见用例包括：

• 发现并连接配套的 Mac 应用或本地服务器：例如手机端 App 与桌面端配套软件在同一局域网内自动配对；
• iOS 设备之间的点对点通信：同局域网内多台 iOS 设备不经云端直接互连；
• 与网络可访问设备集成：如打印机、媒体播放器、IoT 硬件等支持 Bonjour 广播的外设。

从源码与测试的角度看，凡是在 App 中观察到NWBrowser/NWListener/NetService/NetServiceBrowser等 API 引用，即可推断其存在 Bonjour 服务发现面，应纳入 MASTG-BEST-0045 所述"网络型 IPC"安全审查范畴。

Bonjour 的两套 API 体系

iOS 为 Bonjour 提供两代 API 体系，开发者选型直接影响代码审计时的追踪目标：

以 Network framework 为例，广告一个 Bonjour 服务的核心代码如下（示意）：

import Network // 广告侧：NWListener 发布服务 let parameters = NWParameters() parameters.includePeerToPeer = true let listener = try NWListener(using: parameters) listener.service = NWListener.Service(name: "MyAppInstance", type: "_myapp._tcp", txtRecord: ["version": "1.0"]) listener.newConnectionHandler = { connection in connection.start(queue: .main) // 此处才建立真正的数据传输通道 } listener.start(queue: .main) // 浏览侧：NWBrowser 按类型发现服务 let browser = NWBrowser(for: .bonjour(type: "_myapp._tcp", domain: nil), using: parameters) browser.browseResultsChangedHandler = { results, changes in for result in results where result.endpoint != nil { // 发现到远端服务，随后通过 endpoint 建立 NWConnection } } browser.start(queue: .main)

对应的旧式 Foundation 写法（NetService广告 +NetServiceBrowser浏览）仍可在存量代码中见到，审计时两者都应覆盖。需要特别说明的是：服务类型（service type）遵循固定格式_<name>._tcp或_<name>._udp，例如_myapp._tcp。该类型字符串既用于 API 调用，也用于Info.plist的NSBonjourServices声明，是静态检查与运行时流量观察之间的关键关联点。

本地网络访问权限：iOS 14 起的隐私门槛

自iOS 14起，任何通过 Bonjour 等方式访问本地网络的 App，都必须在Info.plist中声明NSLocalNetworkUsageDescription中描述的 iOS 权限分层模型一致：本地网络权限属于"运行时授权 + 用途说明字符串"这一类受保护资源，App 必须同时满足声明与运行时授权两个条件。

同时，使用 Bonjour 的 App 还应通过Info.plist的NSBonjourServices键声明其浏览的服务类型。MASTG 文档给出的最小配置如下：

<key>NSBonjourServices</key> <array> <string>_myapp._tcp</string> </array>

完整声明还应搭配本地网络用途说明：

<key>NSLocalNetworkUsageDescription</key> <string>此 App 需要访问本地网络，以发现并连接同一局域网内的配套设备。</string>

缺少必需的本地网络隐私声明时，Bonjour 浏览或本地网络访问可能失败，或被系统直接拦截——这一行为既影响功能，也是 MASTG 测试中的典型发现项：若 App 实际调用了 Bonjour API 却未声明NSLocalNetworkUsageDescription或NSBonjourServices，即为隐私配置缺陷。

关联 Entitlement：Multicast Networking

除Info.plist声明外，某些场景还涉及签名授权（entitlement）。从 MASTG-KNOW-0077 可知，com.apple.developer.networking.multicastentitlement 允许 App 在 iOS 上发送 IP 组播/广播流量，并允许任意的 Bonjour 浏览或广告。也就是说：

• 普通、受限的 Bonjour 服务发现依赖Info.plist声明（NSLocalNetworkUsageDescription+NSBonjourServices）；
• 需要绕过上述限制（例如浏览未在NSBonjourServices中声明的服务类型，或使用组播通信）的 App，则可能额外携带该 entitlement。

测试人员在提取已签名 App 的 entitlements（可结合代码签名提取技术如 MASTG-TECH-0111 提及的方法）时，若发现com.apple.developer.networking.multicast，应重点确认其用途是否超出功能所需，因为 unnecessary entitlement 会扩大本地网络攻击面。

安全边界与约束：发现 ≠ 信任

Bonjour 本身存在明确的安全边界，MASTG 文档将其归纳为三点，测试时务必逐条核对：

1. 仅限本地发现，不提供互联网级发现或穿越：Bonjour 面向局域网（local network）服务发现，本身不具备互联网规模的发现能力，也不能自行穿越 NAT 或网络边界。若 App 需要跨网络发现，必须依赖其他机制（如后端目录服务）。
2. 发现不加密、不认证后续连接：Bonjour 只负责"找到服务"，发现之后建立的连接是否加密、对端身份是否可信，完全由 App 自行负责。App 有义务为连接施加传输安全（如 TLS）并认证对端（peer）。这意味着测试中绝不能因为"服务是通过 Bonjour 在本地发现的"就假定它安全——本地网络上的任意设备都可能广播同名服务并实施中间人攻击。
3. 本地网络权限是"面"而非"点"：本地网络权限授予的是 App 对整个本地网络的访问权，而不是对某一个 Bonjour 服务类型的访问权。因此 App 仍应声明其浏览的服务类型，并尽量把本地网络使用控制在最小范围。

这一边界在最佳实践中得到进一步强化。根据 MASTG-BEST-0045 的"Secure Network-Based IPC"指导：

Bonjour 提供的是服务发现，而非传输安全。发现之后建立的连接仍需要正常的认证、授权、传输保护和输入校验。不要将"处于本地网络"视为信任信号——必须认证对端、在适当场合加密流量，并校验所有消息。

MASTG 视角下的测试要点

结合上述原理与 MASTG 知识库，针对 Bonjour 的测试可按下述路径开展：

1. 静态配置核查（Info.plist）：检查 App 的Info.plist是否包含NSLocalNetworkUsageDescription；若 App 使用 Bonjour 浏览，确认NSBonjourServices中声明了实际使用的服务类型（与代码中的_<name>._tcp/_<name>._udp字符串比对）。
2. 源码级 API 追踪：在二进制或源码中检索NWBrowser、NWListener、NetService、NetServiceBrowser的引用，确认服务类型、txtRecord暴露的附加信息，以及发现回调之后连接的处理逻辑（是否施加 TLS、是否认证对端）。
3. Entitlements 审查：检查签名中是否含com.apple.developer.networking.multicast等不必要的网络 entitlement。
4. 运行时行为验证：触发 App 的本地网络流程，观察系统是否弹出本地网络权限提示；结合网络抓包确认实际连接是否加密、服务发现是否仅限局域网范围。
5. 威胁建模：将 Bonjour 通道视为不可信输入源——本地网络上的任意设备都能广播服务名，App 对"发现结果"的信任程度、对后续连接数据的输入校验强度，都应作为测试结论写入报告。

延伸阅读

本条目在 MASTG 知识体系中与以下内容直接关联，可结合阅读以形成完整认知：

• MASTG-KNOW-0078：iOS IPC 通道全景，明确 Bonjour 属于网络型通道的定位；
• MASTG-KNOW-0073：iOS 网络 API 分层，理解NWListener/NWBrowser与 Network framework 的关系；
• MASTG-KNOW-0077：iOS 权限分层模型（用途说明字符串、entitlements、运行时授权），本地网络权限属其中一类；
• MASTG-BEST-0045：针对 iOS IPC 通道（含 Bonjour）的最小化数据暴露与对端认证最佳实践。

• 文档
• 教程
• 网络安全