赛门铁克移动威胁防御：OAuth滥用可能会对企业和个人数据造成风险

OAuth是许多iOS和Android应用程序使用的流行授权架构，用于将用户身份验证和授权委派给已知的第三方实体，如Google，Facebook或LinkedIn。这包括企业开发以连接到G Suite的应用程序，或员工每天访问的其他社交媒体应用程序。在移动设备上安装此类应用时，用户会看到如下所示的同意屏幕，要求访问其他Google服务：

用户通常会授予应用访问其Gmail帐户或Google云端硬盘的权限，而无需考虑此访问权限允许应用开发者执行此操作。应用程序开发人员在访问时可以使用多种功能，即使应用程序未在使用中也是如此。这可能会给移动用户带来惊喜，因为他们通常不知道应用可以在线和离线访问的数据量，也不知道与应用共享数据的后果。根据所请求的权限和访问类型，应用程序基本上可以让用户永久进行身份验证，并继续从Gmail，Google云端硬盘，Google日历或其他包含敏感信息的服务访问个人数据。

OAuth和Google授权

要开始使用Google授权服务，应用开发者首先需要从Google Developer's Console注册并获取OAuth客户端凭据。与客户端密钥可以安全地存储在服务器上并与客户端ID结合使用以进行身份验证的Web应用程序不同，移动应用程序没有安全的方式来静态存储客户端密钥。因此，应用程序通常仅使用其公共客户端ID向Google的授权服务器进行身份验证。客户端ID用于交换访问令牌的授权代码。

应用程序开发人员还需要在OAuth许可屏幕中定义他们需要访问的范围（权限）：

在将用户重定向到授权页面时，稍后可以在联机和脱机模式下请求范围。如果在脱机模式下请求范围，则应用程序可以随时请求访问令牌，即使用户处于脱机状态也是如此。上面的图1显示了Microsoft Outlook的同意屏幕，要求在离线模式下完全访问Gmail，Google云端硬盘和Google日历。从图中可以看出，从同意屏幕本身，用户无法知道该应用是否正在请求离线或在线访问。

以下是将用户重定向到Google同意屏幕（图1）的请求，其中包含应用已请求的范围列表。然后，用户可以在同意屏幕上选择“允许”或“拒绝”。

如果最终用户允许访问，则会将授权代码返回给应用程序。该应用可以交换此授权码以获取访问令牌，从而允许其通过Google API读取用户的受保护资源：

在具有公共客户端ID的移动应用程序中，任何可以拦截授权代码的人都可以将其交换为访问令牌。通过添加PKCE（代码交换证明密钥）机制，Google等OAuth提供商可以保护此代码交换流程。使用PKCE，app会生成一个名为“code_verifier”的高熵随机字符串，并在第一个授权请求中将其编码值（“code_challenge”）发送到服务器。在交换访问令牌的授权码时，Code_verifier的原始值被发送到服务器并与先前接收的编码值进行比较。此过程不如在Web应用程序中传递客户端机密一样安全，但它使得在移动应用程序中伪造代码交换请求变得更加困难，在这些应用程序中，可以更容易地窃取静态存储的客户机密码。

响应上述代码交换请求（图3），如果在第一个授权请求中请求了脱机访问类型，则应用程序将接收访问令牌和可选刷新令牌（图2）。在我们的示例中，该应用程序将同时接收：

访问令牌的保质期短，一般在一小时后到期。为了保持连续访问，刷新令牌用于续订访问令牌。如前所述，如果已请求脱机访问类型，则仅向应用程序提供刷新令牌。当用户不在场时需要访问Google API的应用程序需要此访问类型，例如，用于运行计划任务。但是，出于安全原因，必须避免对敏感范围的脱机请求或将其限制为所需的确切功能。对Google和Google云端硬盘的完全访问权限是应用可以要求的两个最受限制的范围，开发人员应该避免并使用其他不太宽松的范围替换它们，如Google Developers Documentation所述。

不总是需要敏感范围

我们的研究表明，限制权限的请求，特别是在离线模式下，对于许多应用程序的主要功能来说不是必需的，并且在大多数情况下可以用不太敏感的范围替换（例如gmail.readonly，gmail.compose，gmail.modify，等等）。

为了演示刷新令牌过程如何在离线模式下发生，我们修改了Approov Books App，这是一个使用AppAuth SDK实现OAuth2的Approov开源代码示例集合。AppAuth是Android和iOS应用程序用于与OAuth 2.0和OpenID Connect提供程序通信的流行SDK。AppAuth库“遵循RFC 8252中规定的最佳实践  - 用于本地应用程序的OAuth 2.0 ”，并且“还支持 对OAuth 的  PKCE扩展，该扩展是为了在使用自定义URI方案重定向时保护公共客户端中的授权代码而创建的。”

我们的演示应用程序要求在离线模式下完全访问Gmail，Google云端硬盘和Google日历。以下是每个范围提供访问权限的说明。

• https://mail.google.com

“完全访问该帐户，包括永久删除线程和消息。只有当您的应用程序需要立即永久删除线程和消息时，才应该请求此范围，绕过“废纸篓”; 所有其他操作都可以使用较不宽松的范围执行。“

• https://www.googleapis.com/auth/drive    

 “访问所有用户文件的完整，允许的范围，不包括  Application Data文件夹。仅在严格必要时才申请此范围。“

• https://www.googleapis.com/auth/calendar          

“查看，编辑，分享和永久删除用户可以使用其Google日历访问的所有日历。”

刷新令牌具有较长的保质期，并受到严格的存储要求，以确保它们不会泄漏。

请参阅下面的视频，其中显示了应用只能使用刷新令牌及其公共客户端ID轻松获取应用外部的新访问令牌。

为了防止令牌泄漏（更有可能发生在应用程序中），某些应用程序会在服务器端数据库中保存应用程序外部的令牌。这个增加的保护层可以保护令牌免受攻击，但它为应用程序开发人员提供了更多权限来保留和/或滥用令牌。   

尽管移动用户常见的假设是，除非应用或用户撤消访问权限，否则无论是从应用或Google注销，还是应用删除都不会导致刷新令牌过期。为防止滥用或暴露用户的敏感数据，应用程序在用户卸载应用程序时撤消指定的访问权限非常重要。令人惊讶的是，在我们使用离线作用域分析到Google API的1800个应用程序中，没有一个在卸载过程中撤消访问权限。这包括已知的电子邮件客户端，如Microsoft Outlook电子邮件和日历应用程序（Android和iOS）。 

以下显示了在离线模式下请求敏感范围的不同类别的应用程序示例。

此外，下图显示了要求在iOS和Android中完全访问Gmail，Google云端硬盘和/或Google日历的应用分布：

有什么风险？

当用户授予应用程序访问其Google服务的权限时，他们实际上允许应用程序开发人员复制其数据并将其存储在开发人员的服务器上。Google 对存储在第三方服务器中的数据的安全性不承担任何责任。这意味着，虽然Google可能会尽最大努力保护用户的电子邮件，但如果他们授予了应用访问Gmail的权限，该应用可以在应用服务器中以非安全的方式存储他们的电子邮件，从而使数据面临风险泄漏

持久访问用户数据会增加风险。想象一下可以访问您的Google云端硬盘的应用。您卸载该应用程序，并假设应用程序开发人员无法再访问您的文件。但是，除非您或开发者撤销授权，否则该应用仍然可以访问您添加到云端硬盘的新文件。

结论和建议

尽管使用OAuth安全技术（如PKCE或基于状态的参数）来防止跨站点请求伪造攻击，但授权滥用防范仍留给开发人员，通常作为“推荐”但仍然是“可选”的选择。不幸的是，这可能打开恶意软件的大门，包括勒索软件，在用户离线时，应用程序外部可能会发生未经授权的文件访问。这也可能导致敏感的公司数据暴露，包括电子邮件，Google云端硬盘文件和日历信息。

在本文中，我们将Google视为主要的OAuth提供商。Facebook和LinkedIn是另外两个受到OAuth安全问题影响的玩家; 与Google相比，这些担忧可能会更小，但对某些组织而言仍然可能很重要。默认情况下，Facebook和LinkedIn中的访问令牌分别在90天和60天后过期，留下较小的利用窗口。但是，Facebook拥有一组永不过期的权限。例如，Publish_pages和Manage_pages可以为应用程序提供无限制访问权限以发布到用户的页面。

基于安全编码最佳实践，应用应该：

• 避免在脱机模式下特别请求敏感权限。敏感权限应替换为应用程序在用户脱机时执行其主要功能所需的较少许可范围。
• 仅在应用程序的主要功能有必要时才要求离线访问。
• 遵循增量授权实践，即请求基本范围，然后在用户想要执行需要其他范围的操作时请求其他范围。
• 每当用户卸载应用程序时，以编程方式撤消给定的访问权限。 

SEP移动保护防止OAuth授权滥用

赛门铁克的移动威胁防御解决方案Symantec Endpoint Protection Mobile（SEP Mobile）使组织能够设置“不受欢迎的应用程序”策略，通过该策略，他们可以降低使用OAuth协议要求过多权限的应用程序的风险。不受欢迎的应用政策允许管理员设置应用被确定为有风险/不需要的条件。管理员可以从应用行为条件列表中选择OAuth滥用和其他漏洞。

符合“使用OAuth请求过多的Google服务权限”条件的应用程序被归类为不需要的，并且可以自动阻止其安装，或者根据组织的策略，如果已安装它们，则可以从设备中删除它们。例如，SEP Mobile在我们的客户安装基础中检测到一个应用程序（下方），该应用程序使用OAuth协议请求过多的Google作用域。该应用被标记为“不需要”，其分类为“OAuth误用”，管理员已收到此事件的警报。根据组织的政策，阻止了应用程序的安装。

OAuth滥用条件包含在SEP Mobile建议的不需要的应用规则中，默认情况下，它是每个新的SEP Mobile环境的一部分。