文档教程网络安全【免费下载链接】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中 iOS 第三方库Third-Party Libraries知识条目 展开系统梳理 iOS 应用引入第三方库的风险面、三大依赖管理工具Swift Package Manager、Carthage、CocoaPods的安全特性并结合仓库中的测试用例、技术条目与可运行 Demo给出从静态扫描、运行时核对到 SBOM 化供应链审计的完整实操方案。读完本文你将能够定位依赖管理产物文件、用 dependency-check 与 Dependency-Track 识别带 CVE 的已知漏洞依赖并制定漏洞出现后的处置与升级策略。为什么第三方库会成为 iOS 应用的安全短板iOS 应用普遍依赖第三方库来加速开发开发者无需从零实现网络栈、JSON 解析、数据库封装等功能就能快速解决业务问题。但引入第三方库的同时也把三方面的风险带进了应用漏洞风险库本身可能携带安全漏洞使整个应用暴露在攻击之下。一个经典案例是AFNetworking2.5.1 版本包含的缺陷会禁用证书校验导致使用该版本连接 API 的应用可被攻击者执行 Machine-in-the-Middle (MITM) 攻击——攻击者可以拦截、篡改应用与服务器之间的通信。维护停滞风险库可能长期无人维护、极少被使用导致其中的漏洞无人报告、无人修复劣质甚至危险的代码被悄悄打包进应用。许可证合规风险库的许可证可能要求应用作者向使用者提供源代码访问权限如 LGPL 2.1应用还可能被允许以修改源码的形式再分发这会直接危及应用的知识产权IP。需要特别指出的是这类问题会在多个层级同时出现如果应用使用 WebView 运行 JavaScript风险同样作用于其中的 JS 库对于 Cordova、React Native 等跨平台移动框架其插件与库也适用相同的分析逻辑。iOS 三大依赖管理工具的安全画像OWASP MASTG 明确指出iOS 生态中最广泛使用的包管理工具有三个各自在实现语言、分发架构与依赖描述文件上存在差异工具支持语言实现语言架构依赖描述/锁定文件Swift Package ManagerSwift、Objective-C、Objective-C、C、CSwift开源、随 Swift 语言分发、自 Xcode 11 起集成于 Xcode、去中心化Package.swift/Package.resolvedCarthageSwift、Objective-CSwift开源、去中心化Cartfile/Cartfile.resolvedCocoaPodsSwift、Objective-CRuby开源、基于集中式注册表公有与私有包Podfile/Podfile.lock从供应链安全角度看这三个文件类型是关键锁定文件resolved/lock记录了项目实际解析出的依赖版本是后续软件成分分析SCA扫描的输入源。开发者可能同时使用多个依赖管理器因此审计时需要逐一收集并扫描对应的产物文件。MASTG 同时将第三方库划分为两类审计时应对其区别对待不应打包进生产应用的库例如测试用的OHHTTPStubs网络请求桩工具会打包进生产应用的库例如AlamofireSwift 网络库。静态分析对依赖管理产物执行 SCA 漏洞扫描针对三种依赖管理器MASTG 提供了完整的 SCA 扫描流程详见已被新测试接管的 MASTG-TEST-0085其新版本为 MASTG-TEST-0273 与 MASTG-TEST-0275。其核心思路是依赖在编译期被打进 IPA 后版本元数据往往会被剥离或改写无法直接扫描成品包因此必须扫描依赖管理器生成的产物文件参见 MASTG-TECH-0133 与 MASTG-TOOL-0131。1. Swift Package Manager扫描 Package.swift / Package.resolved在项目根目录Package.swift所在位置构建以生成锁定文件然后核对实际使用的版本swift build检查Package.resolved中记录的版本再借助 OWASP Dependency-Check 的实验性 SwiftPM Analyzer 识别依赖的 CPECommon Platform Enumeration命名与对应的 CVE 条目dependency-check --enableExperimental --out . --scan Package.swift2. CocoaPods扫描 Podfile.lock / *.podspec在项目根目录Podfile所在位置先安装并生成依赖树sudo gem install cocoapods pod install随后用cocoapods-dependencies插件生成依赖与版本总览作为检索各漏洞源的输入sudo gem install cocoapods-dependencies pod dependencies最后用 Dependency-Check 的 CocoaPods Analyzer 扫描锁定文件或 podspecdependency-check --enableExperimental --out . --scan Podfile.lock实操中还需注意三点若开发者用.podspec将全部依赖封装成自有支持库该 podspec 可用实验性 CocoaPods podspec checker 检查CocoaPods 与 Objective-C 组合的项目可配合 SourceClear 使用下载依赖必须使用 HTTPS——若 Podfile 采用 HTTP 链接依赖下载过程可能被 MITM 劫持攻击者可以替换部分库内容。3. Carthage扫描 Cartfile.resolved在项目根目录Cartfile所在位置更新并构建依赖brew install carthage carthage update --platform iOS然后核对Cartfile.resolved中实际使用的版本并检索已知漏洞。需要说明的是截至 MASTG 撰写本章时Carthage 尚无自动化的依赖分析支持该功能已在 DependencyCheck 上被请求但未实现属于已知的能力缺口。统一扫描命令一个工具覆盖三种管理器MASTG-TECH-0133 给出了基于 Dependency-CheckMASTG-TOOL-0131的统一实操方式。先向 NVD 申请 API Key 以获取最新 CVE 情报然后按所用管理器执行一次只能扫描一个文件# SwiftPM扫描 Package.swift 或 Package.resolved dependency-check --enableExperimental -f SARIF --nvdApiKey YOUR-API-KEY -s Package.resolved # CocoaPods扫描 Podfile.lock 或 *.podspec dependency-check --enableExperimental -f SARIF --nvdApiKey YOUR-API-KEY -s Podfile.lock # Carthage扫描 Cartfile.resolved dependency-check --enableExperimental -f SARIF --nvdApiKey YOUR-API-KEY -s Cartfile.resolved输出始终是 SARIF 格式可用 VSCodeMASTG-TOOL-0133的 SARIF Viewer 插件打开已知漏洞会以 CVE 编号和描述的形式列出。MASTG 提示这些 Analyzer 仍属实验性结果可能有参考价值但需要额外测试以确认误报/漏报率在可接受范围内。实战 Demo扫描 swift-nio 的 Package.resolved仓库中的 MASTG-DEMO-0052 给出了端到端的演示其 Package.resolved 锁定了一个依赖swift-nio版本 2.33.0远程源为https://github.com/apple/swift-nio.git执行 run.sh 中如下命令进行扫描dependency-check --enableExperimental -f SARIF --nvdApiKey $NVD_API_KEY -s Package.resolved生成的 output.txtSARIFdependency-check 10.0.4中至少报告了两条针对pkg:swift/swift-nio2.33.0的 CVECVE-2020-9861高危CVSS v3 7.5Swift for Linux 在处理深层嵌套的恶意 JSON 输入时存在未受控递归导致的栈溢出CVE-2022-1642高危swift-corelibs-foundation的JSONDecoder在 Codable 类型校验与最终类型转换阶段使用了不同的类型擦除方法构造的浮点数字面量可触发确定性崩溃拒绝服务。Demo 的结论是swift-nio至少携带两个已知漏洞CVE-2022-3918 与 CVE-2022-1642 见 Demo 文档output.txt 中另有 CVE-2020-9861应升级到最新版本。评审 SARIF 报告时需逐个核对因为可能存在误报。无源码场景运行时核对应用内库清单当没有源码、只能拿到已安装应用时仍可借助工具识别依赖通常表现为第三方库或 iOS Frameworks 形式。推荐使用 ObjectionMASTG-TOOL-0035也可使用 MASTG-TOOL-0038 或otool -L命令Objection 因其结果准确且易于使用而被推荐它内置了 iOS Bundles 模块提供list_bundles与list_frameworks两个命令。list_bundles列出应用所有与 Frameworks 无关的 bundle输出包含可执行文件名、Bundle ID、库版本与路径...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios bundles list_bundles Executable Bundle Version Path ------------ ----------------------------------------- --------- ------------------------------------------- DVIA-v2 com.highaltitudehacks.DVIAswiftv2.develop 2 ...-1F0C-4DB1-8C39-04ACBFFEE7C8/DVIA-v2.app CoreGlyphs com.apple.CoreGlyphs 1 ...m/Library/CoreServices/CoreGlyphs.bundlelist_frameworks则列出应用中代表 Frameworks 的 bundle...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios bundles list_frameworks Executable Bundle Version Path -------------- ----------------------------------------- --------- ------------------------------------------- Bolts org.cocoapods.Bolts 1.9.0 ...8/DVIA-v2.app/Frameworks/Bolts.framework RealmSwift org.cocoapods.RealmSwift 4.1.1 ...A-v2.app/Frameworks/RealmSwift.framework ...ystem/Library/Frameworks/IOKit.framework ...此外还有两类手动核验路径手工链接的框架打开.xcodeproj项目属性进入Build Phases标签页检查Link Binary With Libraries中的条目复制粘贴的源码若库以源码形式混入工程可搜索头文件Objective-C 场景或 Swift 文件中的已知方法名来识别。对于混合应用Hybrid App还需用 RetireJS 核对 JavaScript 依赖对于跨平台框架应用则需核对其插件与库依赖。面向供应链的 SBOM 路线Dependency-Track 持续监控除了单次扫描MASTG 还提供了基于软件物料清单SBOM的持续性供应链审计方案对应新测试 MASTG-TEST-0275MASWE-0044。首先用 cdxgenMASTG-TOOL-0134 在 Xcode 项目根目录生成 CycloneDX 格式的 SBOM当前仅支持 SwiftPMCarthage 与 CocoaPods 暂不支持MASTG-TECH-0132cdxgen -o sbom.json将 SBOM 做 Base64 编码后通过 REST API 上传到 Dependency-TrackMASTG-TOOL-0132组件分析平台可识别并降低软件供应链风险cat sbom.json | base64 curl -X PUT http://localhost:8081/api/v1/bom \ -H Content-Type: application/json \ -H X-API-Key: YOUR API KEY \ -d ${ project: YOUR PROJECT ID, bom: BASE64-ENCODED SBOM }若生成的 JSON 过大可参考 Dependency-Track 的 CI/CD 上传替代方案。上传后打开前端默认http://localhost:8080在对应项目中核对是否存在带已知漏洞的依赖。注意MASTG-TOOL-0134 对 SwiftPM 生成的 SBOM不包含传递依赖审计时需要评估这一限制的影响。发现漏洞依赖后的处置决策树当确认某个库存在漏洞时MASTG 建议按以下逻辑决策详见 MASTG-TEST-0085库被打包进应用先看是否存在已修复该漏洞的版本若没有评估该漏洞是否实际影响应用若已影响或未来可能影响则寻找功能相似且无漏洞的替代库。库未被打包进应用如构建期工具同样先找已修复版本若无评估漏洞对构建流程的影响——它是否会阻碍构建或削弱构建管线的安全性——再考虑寻找修复了漏洞的替代品。高风险应用最终需对库进行人工审查。原生代码部分应满足与 MASVS 对应用整体一致的要求同时核验其是否遵循软件工程最佳实践。动态验证与许可证合规动态分析包含两部分许可证合规核验与缺失源码时的库清单核验。前者需要确认应用是否遵守各第三方库许可证的版权要求——通常表现为应用内应存在About或EULA章节按许可证要求注明版权声明。后者即在无源码时通过 Objection 等工具列出应用实际加载的库与框架见上文运行时清单方法据此判断是否包含不应出现或未声明许可的组件。延伸隐私清单中的第三方组件供应链风险并不止于 CVE。iOS 应用内的第三方框架也会通过PrivacyInfo.xcprivacy隐私清单声明数据收集行为MASTG 提供了检索这些清单的 MASTG-TECH-0136在解包后的应用目录中执行find . -name PrivacyInfo.xcprivacy即可发现主应用、.bundle、PlugIns、Extensions 与Frameworks/下各第三方框架的隐私清单据此核实第三方库的隐私实践是否符合应用的合规承诺。小结iOS 第三方库审计是一个从资产盘点到持续监控的闭环先用Package.resolved/Podfile.lock/Cartfile.resolved等锁定文件定位依赖版本再用 dependency-checkMASTG-TOOL-0131做 SCA 单次扫描MASTG-TECH-0133、MASTG-TEST-0273或用 cdxgen Dependency-Track 建立 SBOM 化持续监控MASTG-TECH-0132、MASTG-TEST-0275无源码时借助 Objection 的list_bundles/list_frameworks完成运行时核对。对照 MASTG-DEMO-0052 的完整示例你可以将这套流程直接复用到自己的 iOS 项目并在发现 CVE 后按照处置决策树完成升级、替换或人工审查最终把第三方库风险控制在应用可接受的范围内。赞分享文档教程网络安全【免费下载链接】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点击查看免费下载相关推荐Mousetrap.js安全审计第三方库依赖与供应链风险评估Mousetrap.js安全审计第三方库依赖与供应链风险评估 引言 在现代Web开发中第三方JavaScript库的使用已成为常态它们极大地提高了开发效率前端OWASP MASTG 实践指南Android 第三方库安全风险分析与依赖漏洞检测OWASP MASTG 实践指南Android 第三方库安全风险分析与依赖漏洞检测 导读 本指南基于 OWASP Mobile Application Sec文档教程网络安全终极Navi安全风险管理指南全面评估与漏洞扫描实用教程终极Navi安全风险管理指南全面评估与漏洞扫描实用教程 Navi作为一款交互式命令行备忘工具在提升开发效率的同时也面临着安全挑战。本指南将帮助你系统评估Na开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考