政务移动应用安全_移动应用安全中的格局

政务移动应用安全

云和移动应用程序安全性有不同的方面–您可以从不同的角度进行研究。

在21世纪的前十年中，全球互联网从3.5亿增长到超过20亿，移动电话用户从7.5亿增长到50亿-今天达到60亿大关-世界人口约为70亿。 那里的大多数移动设备-甚至最便宜的移动设备都可以用于访问互联网。

让我在这里做一个快速调查。 你们中有多少人使用笔记本电脑进行密码保护？ 答案很明显–几乎全部。 但是您知道吗，只有30％的移动用户使用密码保护他们的移动设备？ 这样一来，就剩下42亿个未受保护的移动设备。 我正在使用多重身份验证来保护我在Google Apps上的公司电子邮件帐户的安全。 我正在使用世界上最致命的密码-有史以来最复杂的密码来保护我的公司Salesforce帐户。 怎么办 ？ 我没有保护手机。 我已经登录到Google Apps –我已经登录到Salesforce。 现在，我所有访问我的移动设备的人都可以访问我的所有机密信息。

密码重置如何？ Google，Microsoft，Yahoo和几乎所有云服务提供商都使用基于手机的密码重置。 拥有对您的移动设备的临时访问权限，某人可以在您的整个生命周期内使用您的帐户。

对于移动应用程序的多因素身份验证也没有被很好地考虑。 这主要是因为存在错误的假设-“我的手机始终在我的控制之下”。 在美国，每分钟丢失或失窃113部手机，每天丢失价值700万美元的智能手机。 Google第二步身份验证和Facebook Code Generator始终都依赖手机来保护基于Web的访问。 但是，它们的移动应用程序都没有受到多因素身份验证的保护。 基于电话的多因素身份验证不适用于移动应用程序。

为什么我们需要在企业层面上担心所有这些？ 当前，有62％的移动工作人员使用其个人智能手机进行工作。

这些是移动世界中众所周知的事实或威胁。 不同的供应商有他们自己的解决方案。 Apple允许您通过Internet锁定设备，甚至清除所有数据。 同样，大多数移动设备管理（MDM）解决方案都使您可以控制丢失的设备。 但是，再说一遍，如果您将其留在错误的手上有多少时间，将会造成足够的损害。 MDM解决方案需要超越其简单的定义，才能成为企业身份管理系统的组成部分。

在过去几年中-几乎-所有云服务提供商都变得对移动设备友好。 他们都提供了基于RESTful JSON的API。 Amazon AWS，Google Cloud Storage，Salesforce，Dropbox都具有REST API。 除AWS之外-所有其他均受OAuth 2.0保护。 AWS使用自己的身份验证方案。

OAuth 2.0在保护REST API方面已“证明成功”。 但是对于移动应用程序，OAuth 2.0可能会产生误导。 它具有四种定义的授权类型。 授权代码，隐式，资源所有者密码和客户端凭据。

授权代码和隐式代码主要用于基于浏览器的应用程序。 在应用程序开发人员中，人们误认为资源所有者和客户端凭据授予类型适用于移动应用程序。 这些要求您直接向应用程序提供凭据。 作为一种实践，避免它。 如果您开发移动应用程序以使用OAuth访问安全的云API，请使用授权代码或隐式授予类型。 在此，您的应用程序需要弹出本机浏览器，以将用户重定向到OAuth授权服务器。

但是–仍然不能使您100％不遭受进一步攻击。 只要通过浏览器进行重定向，就有可能发生网络钓鱼攻击。 流氓OAuth客户端应用程序可以具有“使用Facebook登录”按钮-该按钮会将您重定向到流氓OAuth授权服务器（看起来像Facebook），在其中您会将其误解为Facebook并放弃凭据。

可以采取许多反钓鱼措施。 但是，令人遗憾的是，大多数OAuth授权服务器（包括Facebook和Twitter）都没有遵循。 您的Facebook或Twitter帐户凭据可以很容易地通过移动电话来窃取，而不是从便携式计算机上窃取。 这比您想像的要容易得多。

如果您使用OAuth 2.0开发了移动应用程序，则可能会遇到另一个限制。 您需要烘烤-您的客户端密钥和客户端密钥进入移动应用程序本身。 这是OAuth流程的第一阶段所必需的-这是OAuth授权服务器的客户端标识。 如果有人从设备中窃取了该怎么办？

让我们看一个例子。 我们有一个移动应用程序，它将访问最终用户的Facebook朋友列表，并使用其REST API将该朋友列表存储在Google Cloud Storage中。 Facebook朋友列表属于最终用户，但Google Cloud Storage属于移动应用程序。 移动应用程序必须在Facebook上注册为OAuth客户端，并获取客户端密钥和机密。 然后使用授权码授予类型–它可以获取访问令牌–代表最终用户访问他的最终用户朋友列表。 要将其存储在Google Cloud Storage中，应用程序必须使用客户端凭据授予类型-授权服务器为Google。 为此，我们需要将客户端密钥和客户端密钥放入应用程序本身。 有权访问这些密钥的任何人，也都可以访问Google云端存储。 这是一个仍在研究​​中的领域，尚无永久解决方案。 诸如基于IP地址，设备ID的限制之类的解决方案只会使事情变得更艰难，但并非完全不可能。

OAuth 2.0已成为移动应用程序身份验证的事实上的标准。 这本身就为应用程序提供了更好的在发生攻击时的故障转移功能。 一个很好的例子就是最近对Buffer的攻击-一种社交媒体管理服务，该服务使用户可以交叉发布到Facebook和Twitter等社交网站。 Twitter，Facebook充斥着Buffer的帖子。 但是撤销Buffer的客户端密钥可以解决此问题。 而且，对Buffer的攻击并未将用户的Facebook和Twitter帐户完全控制给攻击者-因为它没有存储密码。

用户平均需要20秒才能登录到资源。 每次用户需要访问资源时都不必输入密码，这样既可以节省时间，又可以提高用户的工作效率，还可以减少多次登录事件和忘记密码的麻烦。 用户只有一个密码要记住和更新，并且只有一组密码规则要记住。 他们的初始登录使他们可以访问所有资源，通常是整天或整个星期。

为移动应用程序构建单一登录解决方案面临哪些挑战？

如果要为公司员工提供多个移动应用程序，以将其安装在他们的移动设备中–要求他们分别重新登录每个应用程序很痛苦。 可能所有这些用户可能共享同一用户存储。 这类似于Facebook用户使用其Facebook凭据登录到多个第三方移动应用程序的情况。

在移动世界中，这可以通过两种方式完成。

首先，每个本地移动应用程序（需要对用户进行身份验证时）都应弹出本地浏览器，并启动OAuth流程。 您的公司应该有一个在公司用户存储之上运行的集中式OAuth授权服务器。 您所有的移动应用程序都将用户重定向到同一授权服务器-在集中式授权服务器的域下创建一个登录会话-间接地促进了单点登录。

另一种方法称为“本地SSO”。 与基于浏览器的SSO相比，本机SSO的用户体验要好得多。 在这里，您需要为公司身份提供商（IdP）或授权服务器开发本机移动应用程序，其他应用程序将调用该本地移动应用程序以启动OAuth流-而不是弹出浏览器。 尽管本机SSO提供了更好的用户体验，但也使网络钓鱼攻击变得更加容易。

本机SSO的另一个缺点是-它具有一个阶段-不基于标准。 您的应用程序应事先知道身份提供者是谁，并应根据其接口进行编程以启动本机SSO。 当前，OpenID Foundation尝试为移动设备上安装的本机应用程序构建标准的单点登录（SSO）模型。 这引入了一个称为授权代理的OpenID Connect客户端-它可以代表其他已安装的本机应用程序获取令牌-从而为这些应用程序提供令牌，从而为最终用户提供单点登录体验。 该规范尚处于初始阶段–在成为标准之前，还需要进行多次迭代。

让我们再举一个例子。 在前面的案例中，我们假设我们只有一个用户存储-位于集中式授权服务器之后。 让我们假设一下。 我们需要域外的用户（例如，来自联盟合作伙伴的用户）访问我们的移动应用程序并使用服务。 需要有一个引导过程来建立那些联盟伙伴与我们的授权服务器之间的信任。 以标准方式进行操作–合作伙伴将需要支持其中的一种联合标准。 最好的是SAML。 因此–我们需要将合​​作伙伴SAML IdP作为受信任的IdP添加到我们的授权服务器。 而且，我们可以针对每个IdP定义授权策略-这样我们就知道它们在我们的授权服务器中将拥有哪些权限。 通过基于浏览器或本机SSO将用户重定向到授权服务器时，他可以选择要对其进行身份验证的IDP。 根据选择，用户将被重定向到其家庭SAML IdP，并且在通过身份验证后，授权服务器将恢复OAuth流。 这是一次性的事情-对于来自其他移动应用程序的其他后续请求-流程对用户而言将是无缝的，并且不需要将其重定向到其本地SAML IdP。

在上面讨论的所有“单一登录”用例中-我们仍然还有一个假设-所有移动应用程序都将具有集中式授权服务器。 让我们也摆脱它。

任何单一登录方案的一项关键要求是–我们应该能够在应用程序及其用户之间建立直接信任或代理信任。 在大多数情况下，这是通过IdP建立的。 我们采用的第一个示例基于直接信任，而第二个示例则基于经纪信任。 为了完成此用例，我们需要在所有授权服务器（参与其中）与中间人之间建立信任关系，以中介SSO。 OpenID Foundation在本机SSO规范草案中也强调了该用例，但到目前为止没有太多细节。

传输中的数据是另一个安全问题。 忘掉NSA和安吉拉·默克尔（Angela Merkel）。 NSA拥有5000多名高能力的计算机科学家-他们可以控制安全算法设计。 因此，让NSA脱颖而出。 在大多数情况下，移动应用程序在传输过程中都依赖TLS进行数据保密。 TLS有其自身的局限性，因为它基于传输，并且数据的机密性在离开传输时终止。 移动应用程序中使用的大多数数据传输通道都使用REST和JSON。 我们有IETF下的JOSE工作组，目前正在努力制定一种标准，以进行消息级加密和JSON负载签名。

让我将讨论转向另一个方向。 托管云API。 Amazon AWS，Google Cloud，Dropbox和Salesforce都通过REST和JSON公开API。 即使在这种情况下，Twitter和Facebook。 我们在这些云API的基础上开发移动应用程序-供我们的公司员工使用。 为了简化说明–我将以Twitter为例。 我们在Twitter上有一个公司帐户，该帐户用于发布与公司相关的事件，并且主要由营销团队使用。 要通过公司帐户进行鸣叫，我们需要与他们共享官方的Twitter密码。 这不理想。 我们不能让他们通过相同的公司帐户发送推文-但仍使用其公司LDAP凭据进行身份验证吗？ 而且-我们需要执行某些规则和政策。 任何提及客户名称的推文都应立即被阻止。 另外，我们需要收集统计数据并进行访问控制。 换句话说，为了满足所有这些要求，我们需要将简单的Twitter API转换为托管API。 在这里，我们在您的移动应用程序和Twitter API之间引入一个API网关。 通过API网关，我们公开了我们自己的API，该API包装了Twitter API。 现在–行销团队可以使用其公司凭据向Twitter Wrapper API进行身份验证，并可以使用公司的Twitter帐户对Tweet进行身份验证。 官方的Twitter凭据从不公开-仅保存在API网关中。 Twitter是一个简单的示例，但您想要将其转换为托管云API的任何云API都适用于移动应用程序。

参考： Facile Login博客上的JCG合作伙伴 Prabath Siriwardena提供的移动应用程序安全性概述。

翻译自: https://www.javacodegeeks.com/2013/11/landscapes-in-mobile-application-security.html

政务移动应用安全