Android P 中的网络安全配置指南

Change 其他 2018年8月23日发布

导语:前言 随着数据隐私变得越来越重要,谷歌一直在试图增强移动操作系统的功能,用以保护Android移动设备和端点的所有数据。Android 9.0 P(Pie)预计在8月发布,其网络通信将默认为TLS。为了防止APP连接失败,Android移动应用程序开发人员将

blog-network-security-config-android-pie.png

前言

随着数据隐私变得越来越重要,谷歌一直在试图增强移动操作系统的功能,用以保护Android移动设备和端点的所有数据。Android 9.0 P(Pie)预计在8月发布,其网络通信将默认为TLS。为了防止APP连接失败,Android移动应用程序开发人员将需要更新其后端服务,以支持HTTPS或实现Android网络安全配置功能。

当Android 6.0 Marshmallow发布时,谷歌提出了把android:usesCleartextTraffic作为防止意外使用明文通信的手段,Android 7.0 Nougat通过引入Android网络安全配置特性来扩展这个属性,这使得开发人员进一步规范了安全通信。Android的网络安全配置被称为Network Security Configuration,它是开发人员为Android应用程序定制的一个XML文件。

你们中的一些人可能认为这听起来很熟悉,因为iOS也使用类似的客户端检查配置,就是我们所说的App Transport Security。虽然与NSAppTranportSecurity相比,Network Security Configuration所提供的保护与其有很多相似之处。但它们在各自的平台上采取了截然不同的方法来实现网络安全。在这里不做赘述,让我们来看看在Android移动应用程序中使用Network Security Configuration的几个好处,并了解如何将其投入到实现该功能的最佳实践中。

实施优点

1.防止回归到明文通信

一条铁则:安全性乃重中之重。Android Network Security Configuration功能提供了一个简单的层,用来保护应用程序在未加密的明文中意外传输的敏感数据。

如果你不知道“未加密的通信”意味着什么,那么让我们设想这样一个情景,假设你的办公室有一个规定——必须通过UPS来运送所有货物。一个新的实习生加入了办公室,负责运送货物到全国各地的办公室。但是实习生忘记了这项规定,并通过一个未知的、不太昂贵的服务来承包了所有货物的转运。Android Network Security Configuration就像是一个发送和接收的管理器,它检查所有入站和出站的货物,并在设备进入未经审核的交付系统之前停止装运,它可以用来防止意外地使用不可信的、未加密的连接。

Android 9最大的变化之一是在默认情况下,cleartextTrafficPermitted允许被设置为false。这意味着,如果你没有看到这个标志被明确设置为false,并且应用程序的API级别低于28,则该标志将被判断为true。

在Network Security Config中使用的cleartextTrafficPermitted标志的另一个能力,是在特定域和子域上执行真正的设置:

Network Security ConfigurationShell

<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
    </domain-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

2.为安全连接设置可信证书颁发机构

可信证书机构(Trusted Certificate Authorities,CA)可以充当信任中介。在前文所说的故事中,办公室安全策略是将货物托付给UPS,但是也可以把业务交给其他物流公司,比如说FedEx、DHL等。归根结底,你信任谁来安全地发送应用程序数据并防止中间人攻击(MITM)呢?而现在,开发人员可以使用Android Network Security Configuration功能来指定他们信任哪些CA来颁发证书,并确保通信的安全。

首先,Android Network Security Configuration给开发者提供了一些可供选择的CA,默认情况下,Android 7 +(Nougat, Oreo and Pie)所使用的信任锚将是预先安装的系统CA证书,称为“system(系统)”:

Trust Anchors: Android 7+Shell

<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
</network-security-config>

在Android 6 (Marshmallow)及其以下的,默认的信任锚还将包括用户安装的证书,称为“user(用户)”:

Trust Anchors: Android 6 and belowShell

<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system"/>
            <certificates src="user"/>
        </trust-anchors>
    </base-config>
</network-security-config>

最后,可以设置自定义信任锚:

Trust Anchors: CustomShell

<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="@raw/my_custom_ca"/>
        </trust-anchors>
    </base-config>
</network-security-config>

3.实施证书锁定

实施证书锁定又增加了一层安全性。让我们重新回顾一下货物运输的故事,如果可信的CA是诸如UPS、FedEx等的公司,那么证书锁定类似于指定你所信任公司的哪项服务来运送你的货物。Android Network Security Configuration特征可以用来限制仅由可信CA颁发的特定证书用以通信。

我们讨论了在以前所研究过的实现证书锁定的方法,在下面的示例中,我们可以针对特定域和子域,将引脚设置为备份,并设置有效日期。

Certificate Pinning with Network Security ConfigShell

<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set expiration="2018-01-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <!-- backup pin -->
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

4.调试应用程序网络连接

Android Network Security Configuration中提供的另一个选项是调试重写。此特性允许你在Network Security Config中设置只有当android:debuggable为true时才可用。例如,你可以使用自定义CA,为质量保证/预生产环境配置自定义信任锚,这会简化封闭环境测试,因为应用商城不接受标记为可调试的应用程序。

Debug OverridesShell

<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

实施建议

你已经了解了部署Network Security Configuration的一些好处,现在让我们来介绍一些实现此文件的最佳实践。

首先,检查应用程序清单,看看它是否有这个特性。查找android:networkSecurityConfig,类似于这样:

Sample Manifest with Network Security ConfigShell

<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
                    ... >
        ...
    </application>
</manifest>

一旦找到了Network Security Configuration文件,就到了检查如何允许明文通信的时候了。

下面的示例代码是一个反例:

Bad Example: cleartext Permissions with Network Security ConfigShell

<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">example.com</domain>
        <domain includeSubdomains="true">cdn.example2.com</domain>
    </domain-config>
    <base-config cleartextTrafficPermitted="true" />
</network-security-config>

虽然这确保了所有到example.com和cdn.example2.com的通信都是通过HTTPS发送的,但是发送给其他域的所有通信都默认可以是明文,这完全违背了Network Security Configuration功能的预期目的——加强保护通过Android设备传输的所有数据的隐私。

如果你的移动应用程序必须以明文发送数据,那么这样做只会加密某些域的通信。此外,还必须仔细检查端点,明确允许HTTP检查敏感数据和其他API相关问题:

Recommended Implementation of cleartext PermissionsShell

<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
        <domain includeSubdomains="true">insecure.cdn.example.com</domain>
    </domain-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

另一个要考虑的是关于cleartextTrafficPermitted标志,它在Android 8及更低版本的默认值为true,因此,在所有应用程序的Network Security Configuration中,要明确将其设置为false。

让我们看看下面的另一个反例:

Bad Example: Default Implementation of Trust Anchors for Android 6 and belowShell

<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system"/>
            <certificates src="user"/>
        </trust-anchors>
    </base-config>
</network-security-config>

在此示例中,我们看到应用程序正在接受其信任锚中的用户证书,这意味着应用程序将以与系统预置证书相同的方式,来信任用户安装的证书。配置应用程序使用的信任锚时,最好仅限制对系统证书的信任,并在必要时限制应用程序内构建的自定义CA,这有助于防止攻击者能够在设备上安装证书来进行中间人攻击(MITM)。作为Android 7中引入的保护措施的一部分,默认情况下,用户安装的证书不像预先安装的证书那样受信任。如前所述, Android 6及更低版本默认接受用户证书,因此,在必要时明确选择“system(系统)”和/或自定义CA并在所有应用中排除“user(用户)”非常重要。

Recommended Implementation of Trust Anchors with Custom CA (When Necessary)Shell

<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system"/>
            <certificates src="@raw/CustomCA"/>
        </trust-anchors>
    </base-config>
</network-security-config>

让我们再来看一个锁定反例:

Bad Example: Certificate Pinning with Network Security ConfigShell

<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set>
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

上面的例子揭示了应用程序中的两个潜在问题。首先,没有设置pin-set的有效期,第二,没有备份引脚——一个聪明的策略是要设置证书有效期并有多个备份引脚的,旋转四个引脚并不是闻所未闻。如果没有明确设置pin的有效期,则应用程序在到期后将无法连接,但是如果你设置了一个有效期,当pin协议失效时,应用程序不是无法连接,而是将故障转移到设备上的系统CA。

Recommended Implementation of Certificate Pinning with Network Security ConfigShell

<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set expiration="2018-01-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <!-- backup pin -->
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

最后,让我们来谈谈Network Security Config调试的重写。

Recommended Implementation of Debug Overrides with Network Security ConfigShell

<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

虽然调试功能可以帮助消除应用程序中的调试网络代码,但请务必删除应用程序中的任何调试CA。作为一个最佳操作,应避免在你的应用程序中留下任何不必要的信息,因为这可能会带来安全风险,特别是当内部CA证书包含在应用程序的最终产品构建中时。

小结

从安全分析员的角度来看,知道如何在网络安全配置中读取和发现问题是很重要的。正如我们所看到的,在安装之前,我们可以在应用程序中找到一些潜在的问题,但是请记住,这些发现本身并不能证明你的应用程序的网络连接是安全的。

首先,你需要确定你的应用程序是否正在执行主机名验证,因为Network Security Configuration的保护不能解决此类问题。然后,确保你的第三方库符合Network Security Configuration,如果不这样做的话,可能会导致你的应用程序出现问题。此外,Network Security Configuration不受较低级别的网络连接(如websockets)的支持。最后你要记住,移动中的网络相关问题只是移动测试总体范围的一小部分。

总体而言,Android Network Security Configuration为Android提供了许多简单的网络安全功能,如果你的应用程序目前没有利用Network Security Configuration,你必须在未来一年中使用它。

与Android P的发布同步,谷歌已经开始在应用程序商城中实施目标API级别,以减少移动操作系统碎片,并将用户推向当前版本。虽然谷歌计划逐步增加每一个新版本的数量,但是目前的需求仍是26,不过到明年这个时候,API级别30(Android Q)很可能会被淘汰,这意味着如果你的应用程序使用HTTP,则必须在Network Security Configuration文件中声明,因为那时的强制目标API级别将为28。

本文翻译自:https://www.nowsecure.com/blog/2018/08/15/a-security-analysts-guide-to-network-security-configuration-in-android-p/如若转载,请注明原文地址: http://www.4hou.com/technology/13149.html
点赞 5
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论