最小化 iOS 权限与 Entitlements：MASTG-BEST-0051 在 OWASP MASTG 中的实战落地指南

文档教程网络安全【免费下载链接】mastgThe OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载导读本文围绕 OWASP Mobile Application Security Testing GuideMASTG的最佳实践 MASTG-BEST-0051Minimize iOS Permissions and Entitlements展开系统讲解 iOS 应用应如何按最小权限原则收敛权限声明与授权能力capabilities。你将掌握 iOS 权限模型的三个层次purpose strings、entitlements、运行时授权、发布前的三类审查对象、更窄访问路径的选择标准以及如何结合 MASTG 仓库中的知识条目、测试用例与二进制提取技术如rabin2、ldid、codesign将这一最佳实践落地为可验证的静态与动态分析流程。核心原则只请求真正需要的权限与能力MASTG-BEST-0051 的核心主张非常明确只请求应用实际需要的 iOS 权限和应用能力app capabilities并为每个功能优先选择 Apple 支持的最窄访问模型。这样做有两个直接收益减少不必要的个人数据暴露每个额外的权限声明都可能把用户的相机、位置、通讯录、照片库等敏感数据带入应用的处理范围限制爆炸半径blast radius如果应用、某个扩展extension或共享容器shared container日后被滥用冗余的权限与授权会让攻击面随之扩大。该最佳实践进一步要求在发布前将Info.plist中的 purpose strings用途描述字符串、已签名的 entitlements 以及 provisioning profile 中的 entitlements 放在一起审查。一个权限提示或 capability 应当映射到一个用户能理解、且确实存在的具体功能对于以防万一just in case才保留的未使用或投机性条目应当删除而不是保留。该实践在 MASTG 中归属于平台交互MASVS-PLATFORM维度其对应知识条目为 MASTG-KNOW-0077App Permissions并由 tests-beta/ios/MASVS-PRIVACY/ 下的 MASTG-TEST-03600363 四个测试用例具体承接详见后文。先理解 iOS 的三层权限模型要最小化权限必须先厘清 iOS 与 Android 的权限模型差异。如 MASTG-KNOW-0077 所述在 Android 上权限声明在 manifest 中、安装时或运行时授予而在 iOS 上所有第三方应用都以非特权mobile用户运行并通过 TrustedBSD MACMandatory Access Control强制访问控制框架进行沙箱隔离。这个基础沙箱是自动生效的不属于权限范畴。超出沙箱的资源访问由三种不同机制控制用途描述字符串usage description strings / purpose strings位于Info.plist在系统弹出授权提示时向用户解释为何访问受保护资源是系统展示授权弹窗的前提条件Entitlements签名进二进制代码签名中的键值对用于启用特定的平台服务或跨应用数据共享运行时授权请求runtime authorization应用在运行时通过框架 API 请求系统向用户弹出授权提示。三者不是互斥的。一个功能可能需要用途描述字符串、可能需要 entitlement、可能两者都需要、也可能都不需要具体取决于应用调用的 API。例如 HealthKit 就是典型的分层模型需要 Xcode 中启用 HealthKit capability写入com.apple.developer.healthkitentitlement在Info.plist中加入NSHealthShareUsageDescription/NSHealthUpdateUsageDescription再在运行时通过HKHealthStore请求授权——只加 entitlement 是不够的。从源码结构还可以推断另一个实际后果并非所有权限都对用户可见或由用户授予。有些是纯开发者侧配置如通过 entitlement 启用 Data Protection、Keychain Sharing安装时即生效而相机、麦克风、位置、通讯录、日历、照片、健康、蓝牙、运动、语音识别等资源需要运行时授权提示。用户随时可以在设置中授予或撤销访问因此应用通常需要先用专用 API 检查授权状态例如CLLocationManager.authorizationStatus、PHPhotoLibrary.authorizationStatus(for:)、CBManager.authorization等这些 API 同时也是动态分析时判断应用是否真正触达权限层的运行时追踪点。发布前的三类审查对象MASTG-BEST-0051 明确要求把三类来源放在一起审查。对应地MASTG 中较早的测试用例 MASTG-TEST-0069Testing App Permissions已废弃被 MASTG-TEST-03600363 取代也把静态分析归结为以下检查面Info.plist中的 purpose strings检查所有以UsageDescription结尾的键代码签名 entitlements 文件.entitlementsXcode 自动生成、开发者也可能手动编辑内嵌 provisioning profile即Payload/appname.app/embedded.mobileprovision编译产物二进制内嵌的 entitlements源码中对权限的实际使用。检查 Info.plist 中的 purpose strings有源码时在 Xcode 中打开项目、找到Info.plist搜索以Privacy -开头的键切换为原始键值视图Show Raw Keys/Values后Privacy - Location When In Use Usage Description会显示为NSLocationWhenInUseUsageDescription。仅有 IPA 时解压后Info.plist位于Payload/appname.app/Info.plist必要时先用plutil -convert xml1 Info.plist转换格式再检查。典型的条目形如plist version1.0 dict keyNSLocationWhenInUseUsageDescription/key stringYour location is used to provide turn-by-turn directions to your destination./string /dict /plist逐个判断每个 purpose string 是否合理。MASTG-TEST-0069 中给出的反面示例是一个纸牌Solitaire游戏的Info.plist里同时出现NSHealthClinicalHealthRecordsShareUsageDescription和NSCameraUsageDescription——普通纸牌游戏既不需要摄像头也不需要健康记录这显然属于权限过度索取。此外某些 purpose string 还牵涉数据存储语义例如NSPhotoLibraryUsageDescription属于沙箱外文件访问权限如果应用声明了它就应当进一步验证没有敏感数据被存入相册这类其他应用也可能访问的位置。检查 provisioning profile 与二进制中的 entitlementsembedded.mobileprovision不是 plist而是使用 Cryptographic Message SyntaxCMS编码的。在 macOS 上可用security cms -D -i embedded.mobileprovision解码然后在输出中查找keyEntitlements/key区域。需要特别注意的是对应 MASTG-KNOW-0077 的说明embedded.mobileprovision在多种常见场景下并不存在模拟器构建不携带 provisioning profile、伪签名/adhoc 签名构建如用 ldid 直接写入 entitlements见 MASTG-TOOL-0111 相关说明以及App Store 分发版本App Store 处理流程中会被重新签名。因此从应用二进制代码签名中提取 entitlements 是比依赖embedded.mobileprovision更可靠的来源。从 Mach-O 二进制提取 entitlementsMASTG-TECH-0111Extracting Entitlements from MachO Binaries 提供了四种工具的命令可直接用于审查rabin2MASTG-TOOL-0129rabin2 -OC binaryldidMASTG-TOOL-0111ldid -e -A16777228:0 binary16777228:0即CPU_TYPE_ARM64:CPU_SUBTYPE_ARM64_ALLipswMASTG-TOOL-0105ipsw macho info -e binarycodesignMASTG-TOOL-0114codesign -d --entitlements - binary注意保留末尾的-。典型的提取输出会包含application-identifier、com.apple.developer.team-identifier、get-task-allow等基础键以及应用实际申请的授权键。例如 MASTG-KNOW-0077 中给出的 App Groups entitlement 示例keycom.apple.security.application-groups/key array stringgroup.ph.telegra.Telegraph/string /array该 entitlement 本身不需要用户额外授权但正是它让应用之间可以通过 IPC 或共享文件容器直接共享设备上的数据——这正是 MASTG-BEST-0051 要求把数据共享能力当作敏感设计决策的原因。偏好更窄的访问路径Prefer Narrower Access Paths当 Apple 提供了用户选择式或受限式访问 API 时应当优先于大范围库访问或后台访问照片选择当用户只需挑选特定照片时使用PHPickerViewControlleriOS 14UIKit或PhotosPickeriOS 16SwiftUI而不是请求完整相册读写权限。这两个 API 在独立进程中运行只把用户选中的图片以只读方式交给应用这是避免申请不必要权限的首选方案MASTG-KNOW-0077 明确给出了这一建议。仅在应用确实需要全库访问时才申请完整照片库权限。位置访问先请求when in use使用时授权仅在功能确实需要时才考虑更宽泛的后台/始终访问。MASTG-KNOW-0077 指出许多位置驱动功能都可以用when in use而非持久后台访问实现。蓝牙、HealthKit、HomeKit、Siri 等其他受保护服务只启用实现功能集严格必需的 capabilities 和 usage-description 键。从 MASTG-KNOW-0077 的表述还可以推断一个边界场景典型的扫码应用显然需要相机才能工作但可能同时申请了照片权限如果确实需要保存图片且图片本身敏感更稳妥的选择是把图片存入应用沙箱存储避免其他拥有照片权限的应用读取。最小化数据共享能力Minimize Data-Sharing CapabilitiesMASTG-BEST-0051 将App Groupscom.apple.security.application-groups、iCloud 容器如com.apple.developer.icloud-container-identifiers和Associated Domainscom.apple.developer.associated-domains等 entitlements 定位为敏感设计决策而非默认便利设施。它们会为跨应用、扩展、网站或设备的共享、同步或暴露个人数据创造新路径。启用之前应完成三件事记录该能力解锁的精确数据流记录需要它的最小目标集targets记录事后保护这些数据的安全控制措施。如果同一功能可以在不引入大范围共享容器或外部关联的情况下实现优先选择更窄的设计。MASTG-KNOW-0077 补充了另一个视角取决于待共享数据的性质也许通过后端共享并加以校验比设备上应用间直连共享更合适可以避免用户自身篡改等风险。常见的隐私相关 entitlements 及其对应运行时 API/入口来自 MASTG-KNOW-0077 与 MASTG-TEST-0362包括Entitlement / 能力关联 API 或入口com.apple.developer.healthkitHKHealthStore、HealthKit 数据类型临床记录还需com.apple.developer.healthkit.accesscom.apple.security.application-groupsFileManager.containerURL(forSecurityApplicationGroupIdentifier:)、UserDefaults(suiteName:)com.apple.developer.icloud-container-identifiersCKContainerCKContainer.init(identifier:)要求容器标识符出现在 entitlement 中com.apple.developer.homekitHMHomeManager及HMHomeManager.authorizationStatuscom.apple.developer.associated-domainsNSUserActivityTypeBrowsingWeb、Universal Link 延续处理com.apple.developer.networking.multicastNWConnectionGroupcom.apple.developer.siriIntentsINIntentHandlerProviding.handler(for:)、App Intentspurpose strings 与框架 API 的映射关系MASTG-KNOW-0077 强调usage description 键与运行时 API 是 iOS 权限模型的两个独立部分——前者提供用户可见文案后者请求/检查授权并访问资源。审查时必须同时核对两者。以下是该知识条目给出的常见受保护资源映射表节选关键行受保护资源Usage description 键代表性框架 API位置NSLocationWhenInUseUsageDescription、NSLocationAlwaysAndWhenInUseUsageDescriptionCLLocationManager.requestWhenInUseAuthorization()、requestAlwaysAuthorization()、authorizationStatus()相机NSCameraUsageDescriptionAVCaptureDevice.requestAccess(for:completionHandler:)、authorizationStatus(for:)麦克风NSMicrophoneUsageDescriptionAVAudioApplication.requestRecordPermission(completionHandler:)、recordPermission通讯录NSContactsUsageDescriptionCNContactStore.requestAccess(for:completionHandler:)、authorizationStatus(for:)日历NSCalendarsFullAccessUsageDescription、NSCalendarsWriteOnlyAccessUsageDescriptionEKEventStore.requestFullAccessToEvents(completion:)、requestWriteOnlyAccessToEvents(completion:)照片NSPhotoLibraryUsageDescription、NSPhotoLibraryAddUsageDescriptionPHPhotoLibrary.requestAuthorization(for:handler:)、authorizationStatus(for:)蓝牙NSBluetoothAlwaysUsageDescriptionCBManager.authorization、CBCentralManager、CBPeripheralManager健康NSHealthShareUsageDescription、NSHealthUpdateUsageDescriptionHKHealthStore.requestAuthorization(toShare:read:completion:)、authorizationStatus(for:)运动NSMotionUsageDescriptionCMMotionActivityManager.authorizationStatus()、startActivityUpdates(to:withHandler:)Face IDNSFaceIDUsageDescriptionLAContext.evaluatePolicy(_:localizedReason:reply:)HomeKitNSHomeKitUsageDescriptionHMHomeManager、HMHomeManager.authorizationStatusSiriNSSiriUsageDescriptionINPreferences.requestSiriAuthorization(_:)、siriAuthorizationStatus()语音识别NSSpeechRecognitionUsageDescriptionSFSpeechRecognizer.requestAuthorization(_:)、authorizationStatus()MASTG-KNOW-0077 还给出了一个重要的审查纪律声明了 usage description 键不能证明应用真的访问了受保护资源代码中引用了 API也不能证明该代码路径可达。必须把 purpose strings、静态 API 引用、运行时轨迹、应用功能和用户触发的流程结合起来才能判定受保护资源访问是否合理。将最佳实践落地为测试MASTG-TEST-03600363MASTG-BEST-0051 在测试套件中被 tests-beta/ios/MASVS-PRIVACY/ 下的四个用例承接分别从静态/动态两个维度验证权限与 entitlements 的最小化MASTG-TEST-0360Purpose String Accuracy for Reachable Protected Resource Access静态、配置、人工检查。解包 IPAMASTG-TECH-0058、读取Info.plistMASTG-TECH-0153、必要时转换格式MASTG-TECH-0138、检查所有*UsageDescription键MASTG-TECH-0154、在二进制中查找相关 APIMASTG-TECH-0066。判定失败的条件是存在可达代码路径请求/访问受保护资源但 purpose string 没有有意义、准确、具体地解释原因或可达代码路径缺少必需 purpose string。MASTG-TEST-0361Runtime Use of Protected Resource APIs Without Accurate Purpose Strings0360 的动态对应用例。安装应用MASTG-TECH-0056、hook 相关 APIMASTG-TECH-0095、尽可能触发各种流程记录每个调用的方法/类名、参数、返回值或授权状态、调用栈/backtrace、触发该调用的用户动作或界面以及是否弹出系统授权提示和显示的 purpose string。MASTG-TEST-0362Entitlements for Unjustified Capability Exposure静态、包级检查。用 MASTG-TECH-0111 从主应用和扩展的二进制中提取 entitlements再用 MASTG-TECH-0066 查找与这些 entitlements 相关的框架 API、共享容器 API、标识符或系统入口。该用例指出未使用的 entitlement 本身通常不是直接的隐私违规风险在于潜在latent能力暴露——应用被签名拥有了某个权利一旦应用、扩展、内嵌框架、功能开关feature flag、被攻破的代码路径或后续更新开始使用相关 API就能访问对应服务。最清晰的框架是最小权限least privilege。MASTG-TEST-0363Runtime Use of Entitlement-Backed APIs for Unjustified Capability Exposure0362 的动态对应用例验证应用运行时实际到达的 entitlement-backed API、共享容器或系统入口是否被用户可见功能所证明优先关注影响个人数据、共享存储、跨应用通信、云数据、家庭数据、网络行为或系统入口的行为。两个动态用例0361、0363都强调缺失即无证据的纪律未触发的流程、依赖账号/设备/位置状态、远程配置、功能开关、后端响应、不可用硬件或扩展的代码路径都可能被动态分析漏掉静态分析也可能漏掉动态解析、混淆、原生库、弱链接框架中的 API。因此静态与动态必须互相补充。动态追踪示例frida-trace 验证权限实际使用在无源码场景下验证权限使用MASTG-TEST-0069 给出了一套静态/动态交替迭代的方法论核心步骤是依据静态分析得出的权限/能力清单如NSLocationWhenInUseUsageDescription映射到对应系统框架的专用 API如 Core Location用frida-trace追踪这些 API 的类或具体方法识别应用访问相关功能时实际调用的方法对这些方法取 backtrace构建调用图再以新发现的方法继续喂给步骤 3持续迭代。例如追踪所有包含authorizationStatus的方法frida-trace -U Telegram -m *[* *authorizationStatus*]触发位置分享后可以看到[CLLocationManager authorizationStatus]被调用并返回0x4CLAuthorizationStatus.authorizedWhenInUse。修改自动生成的 handler 脚本可以进一步获取返回值与调用栈// __handlers__/__CLLocationManager_authorizationStatus_.js onEnter: function (log, args, state) { log([CLLocationManager authorizationStatus]); log(Called from:\n Thread.backtrace(this.context, Backtracer.ACCURATE) .map(DebugSymbol.fromAddress).join(\n\t) \n); }, onLeave: function (log, retval, state) { console.log(RET : retval.toString()); }这种方法能确认哪些权限 API 是应用真实触达的从而把声明了权限和实际使用权限区分开——这正是 MASTG-BEST-0051 最小化原则在审查环节的落地。补充privacy manifests 与 required-reason APIsMASTG-BEST-0051 在文末以注记形式明确了一个边界较新的 Apple 隐私机制如隐私清单privacy manifests和 required-reason APIs是对上述检查的补充但不会取代 purpose strings 或 entitlements。也就是说即使应用已经提供了隐私清单、说明了 required-reason API 的使用理由开发者/审查者仍然需要最小化并审查 purpose strings 与 entitlements 两者。这三类机制共同构成受保护资源访问的完整证据链缺一不可。实践检查清单基于本文的全部内容可将 MASTG-BEST-0051 落成一份发布前检查清单枚举列出Info.plist中全部*UsageDescription键以及从二进制签名MASTG-TECH-0111和embedded.mobileprovision如有中提取的全部 entitlements映射将每个权限/能力映射到具体、用户可见的功能而不是以防万一收窄照片选择优先PHPickerViewController/PhotosPicker位置优先when in use蓝牙/健康/HomeKit/Siri 等只启用功能必需的键与能力审视数据共享对 App Groups、iCloud 容器、Associated Domains 等记录数据流、最小目标集与事后安全控制优先选择更窄设计验证以 MASTG-TEST-03600363 为模板用静态分析purpose string 与 API 引用结合动态分析frida 等 hook 运行时真实调用确认声明使用清理删除所有未使用、投机性或与功能无合理关联的权限声明与 entitlements避免潜在的latent能力暴露复核确认 privacy manifests 与 required-reason APIs 已覆盖但依然保持对 purpose strings 与 entitlements 的独立最小化审查。每一步都可以在 MASTG-KNOW-0077、MASTG-KNOW-0058App Signingentitlements 因嵌入代码签名而受签名保护、不可事后修改、MASTG-TECH-0111 及 tests-beta/ios/MASVS-PRIVACY/ 测试用例中找到对应的仓库级证据按图索骥即可完成一次完整的 iOS 权限与 entitlements 最小化审查。赞分享文档教程网络安全【免费下载链接】mastgThe OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载相关推荐OWASP MASTG 实践在 iOS 应用中实现抗调试Anti-Debugging检测的最佳实践MASTG-BEST-0074 深度指南OWASP MASTG 实践在 iOS 应用中实现抗调试Anti Debugging检测的最佳实践MASTG BEST 0074 深度指南 导读 本文文档教程网络安全OWASP MASTG 最佳实践 MASTG-BEST-0042iOS 应用如何在 ATS 配置中坚持强 TLS 设置OWASP MASTG 最佳实践 MASTG BEST 0042iOS 应用如何在 ATS 配置中坚持强 TLS 设置 导读 本文围绕 OWASP Mobi文档教程网络安全OWASP MASTG 最佳实践Android ContentProvider 中的 SQL 注入防护指南MASTG-BEST-0039OWASP MASTG 最佳实践Android ContentProvider 中的 SQL 注入防护指南MASTG BEST 0039 ContentP文档教程网络安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考