跳过内容

移动应用用户隐私保护

概述

重要声明： MASTG 不是法律手册，此处不会详细介绍 GDPR 或其他可能相关的法律。相反，本章将向您介绍与用户隐私保护相关的主题，为您提供必要的参考资料供您自行研究，并提供测试或指南，以确定应用程序是否符合 OWASP MASVS 中列出的与隐私相关的要求。

主要问题

移动应用处理各种敏感用户数据，从身份识别和银行信息到健康数据，因此开发人员和公众都理所当然地关心这些数据的处理方式以及最终去向。还值得讨论“用户使用应用程序获得的好处”与“他们为此付出的实际代价”（通常甚至没有意识到）之间的关系。

解决方案（2020 年之前）

为了确保用户得到适当的保护，已经制定并部署了诸如欧盟的 通用数据保护条例 (GDPR) 等法律（自 2018 年 5 月 25 日起适用）。这些法律可以迫使开发人员在处理敏感用户数据方面更加透明，这通常通过隐私政策来实现。

挑战

考虑以下移动应用隐私的维度

  • 开发人员合规性：开发人员需要了解有关用户隐私的法律，以使其工作符合要求。理想情况下，必须遵循以下原则
    • 隐私设计方法（第 25 条 GDPR，“通过设计和默认的数据保护”）。
    • 最小权限原则（“系统的每个程序和每个用户都应使用完成工作所需的最小权限集进行操作。”）
  • 用户教育：需要对用户进行有关其敏感数据的教育，并告知他们如何正确使用应用程序（以确保安全地处理和处理其信息）。

注意：通常，应用程序会声称处理某些数据，但实际上并非如此。 IEEE 文章 Majid Hatamian 撰写的“在智能手机应用程序中设计隐私：应用程序开发人员的技术指南目录” 对此主题进行了很好的介绍。

数据保护目标

当应用程序从用户那里请求个人信息时，用户需要知道应用程序为什么需要该数据以及应用程序如何使用该数据。如果第三方正在进行数据的实际处理，则应用程序也应告知用户。

与安全保护目标的经典三要素类似：保密性、完整性和可用性，已提出三个数据保护目标

  • 不可链接性:
    • 用户的隐私相关数据与域外的任何其他隐私相关数据集合不相关。
    • 包括：数据最小化、匿名化、假名化等。
  • 透明度:
    • 用户应知道如何请求应用程序拥有的有关他们的所有信息，并了解应用程序拥有的有关他们的所有信息。
    • 包括：隐私政策、用户教育、适当的日志记录和审计机制等。
  • 可干预性:
    • 用户应知道如何更正其个人信息，请求删除个人信息，随时撤回任何给定的同意，并接收有关如何执行此操作的说明。
    • 包括：应用程序中的隐私设置、个人干预请求的单一联系点（例如，应用内聊天、电话号码、电子邮件）等。

有关更多详细信息，请参见 ENISA 的 “移动应用程序中的隐私和数据保护”中的第 5.1.1 节“数据保护目标简介”。

由于同时解决安全和隐私保护目标非常具有挑战性（如果在许多情况下并非不可能），因此值得研究 IEEE 出版物 隐私工程的保护目标 中名为 “三个轴” 的可视化图，这有助于我们理解为什么我们无法同时达到所有六个目标的 100%。

虽然隐私政策传统上保护了这些过程中的大部分，但这种方法并不总是最佳的，因为

  • 开发人员不是法律专家，但仍需要遵守法律。
  • 用户几乎总是必须阅读冗长而冗长的政策。

新方法（Google 和 Apple）

为了应对这些挑战并更好地告知用户，Google 和 Apple 引入了新的隐私标签系统（非常类似于 NIST 的提案），以帮助用户轻松了解如何收集、处理和共享他们的数据，消费者软件网络安全标签。他们的做法可以在以下网址看到

由于这是两个平台上的新要求，因此这些标签必须准确，才能让用户放心并减轻滥用。

Google ADA MASA 计划

由于定期安全测试有助于开发人员识别应用程序中的关键漏洞，因此 Google Play 将允许已完成独立安全验证的开发人员通过在应用程序的“数据安全”部分中披露这一事实来告知用户。开发人员对安全和隐私的承诺旨在让用户放心。

作为为应用程序的安全架构提供更多透明度的过程的一部分，Google 推出了 MASA（移动应用程序安全评估）计划，作为 应用程序防御联盟 (ADA) 的一部分。由于 MASA 是移动应用程序生态系统公认的全球移动应用程序安全标准，因此 Google 承认安全在该行业中的重要性。开发人员可以直接与授权实验室合作伙伴合作，启动针对一组 MASVS 1 级要求的独立验证的安全评估，并且 Google 将通过允许他们在应用程序的“数据安全”部分中披露这些测试来认可这一努力。

如果您是开发人员并且想要参与，请填写 独立安全审核表。

当然，测试是有限的，它并不能保证应用程序的完全安全。独立审核的范围可能不会验证开发人员的数据安全声明的准确性和完整性，并且开发人员仍然有责任在其应用程序的 Play 商店列表中做出完整而准确的声明。

参考资料

您可以在此处了解有关此主题和其他隐私相关主题的更多信息

移动应用中的隐私测试

安全测试人员应了解 Google Play 的 常见隐私违规列表，尽管它并不详尽。以下是一些示例

  • 示例 1：一个应用程序访问用户已安装的应用程序清单，并且不将此数据视为个人或敏感数据，而是通过网络发送（违反 MSTG-STORAGE-4）或通过 IPC 机制发送到另一个应用程序（违反 MSTG-STORAGE-6）。
  • 示例 2：一个应用程序在未经用户授权的情况下显示敏感数据，例如信用卡详细信息或用户密码，例如生物识别技术（违反 MSTG-AUTH-10）。
  • 示例 3：一个应用程序访问用户的电话或联系人簿数据，并且不将此数据视为个人或敏感数据，此外还通过不安全的网络连接发送它（违反 MSTG-NETWORK-1）。
  • 示例 4：一个应用程序收集设备位置（这显然不是其正常运行所必需的），并且没有突出显示解释哪个功能使用此数据的披露信息（违反 MSTG-PLATFORM-1）。

您可以通过转到政策中心 -> 隐私、欺骗和设备滥用 -> 用户数据，在 Google Play Console 帮助 中找到更多常见违规行为。

正如您可能期望的那样，这些测试类别彼此相关。当您测试它们时，您通常间接测试用户隐私保护。这一事实将使您能够提供更好，更全面的报告。通常，您将能够重用其他测试中的证据，以便测试用户隐私保护）。

应用市场上的数据隐私披露测试

本文档仅对确定开发人员正在披露哪些与隐私相关的信息感兴趣，并讨论如何评估此信息以确定其是否合理（类似于您在测试权限时所做的那样）。

虽然开发人员可能未声明某些确实被收集和/或共享的信息，但这是另一个测试的主题。在此测试中，您不应提供隐私违规保证。

静态分析

要执行静态分析，请按照以下步骤操作

  1. 在相应的应用市场（例如，Google Play，App Store）中搜索该应用。
  2. 转到 “隐私详细信息”（App Store）或 “安全部分”（Google Play）部分。
  3. 确定是否根本有任何可用信息。

只要开发人员遵守了应用市场准则并包含所需的标签和解释，该应用就可以通过测试。开发人员在应用市场中的披露信息应存储为证据，以便您以后可以使用它来确定潜在的隐私或数据保护违规行为。

动态分析

作为可选步骤，您还可以在此测试中提供某种证据。例如，如果您正在测试 iOS 应用程序，则可以轻松启用应用程序活动记录并导出 隐私报告，其中包含应用程序对不同资源的详细访问权限，例如照片、联系人、相机、麦克风、网络连接等。

动态分析对于测试其他 MASVS 类别具有许多优势，并且它提供了非常有用的信息，您可以使用这些信息来 测试网络通信 以用于 MASVS-NETWORK 或在 测试应用与平台的交互 以用于 MASVS-PLATFORM。在测试其他这些类别时，您可能已经使用其他测试工具进行了类似的测量。您也可以将其作为此测试的证据提供。

虽然应将可用信息与应用程序实际要执行的操作进行比较，但这将远非一项简单的任务，可能需要几天到几周的时间才能完成，具体取决于您的资源和自动化工具的功能。这些测试还严重依赖于应用程序的功能和上下文，并且理想情况下应在与应用程序开发人员密切合作的白盒设置中执行。

用户安全最佳实践教育测试

如果您打算自动化该过程，则确定应用程序是否教育用户并帮助他们理解安全需求尤其具有挑战性。我们建议广泛使用该应用程序，并在适用的情况下尝试回答以下问题

  • 指纹使用情况：当指纹用于身份验证，提供对高风险交易/信息的访问时，

    该应用是否告知用户将其他人的多个指纹注册到设备时可能出现的问题？

  • Rooting/越狱：当实现 root 或越狱检测时，

    该应用是否告知用户，由于设备的越狱/root 状态，某些高风险操作将带来额外的风险？

  • 特定凭据：当用户从应用程序获得恢复代码、密码或 PIN 码时（或设置一个时），

    该应用是否指示用户永远不要与他人分享，并且只有该应用会请求它？

  • 应用分发：对于高风险应用，为了防止用户下载受损的应用版本，

    应用制造商是否正确地传达了分发应用的官方方式（例如，从 Google Play 或 App Store）？

  • 突出显示披露信息：在任何情况下，

    该应用是否显示对数据访问、收集、使用和共享的突出显示披露信息？例如，该应用是否使用 App Tracking Transparency Framework 来请求 iOS 上的权限？

其他参考资料包括