Guía para la configuración de la seguridad de la red en Android P

A medida que la privacidad de los datos se vuelve cada vez más importante, Google ha introducido mejoras en el sistema operativo móvil para proteger todos los datos que atraviesan los dispositivos móviles y terminales Android. Programado para su lanzamiento en agosto de 2018, las comunicaciones de red en Android 9.0 P (Pie) se establecerán de forma predeterminada en TLS. Los desarrolladores de aplicaciones móviles de Android deberán actualizar sus servicios de back-end para admitir HTTPS o implementar la función de configuración de seguridad de red de Android para evitar que las conexiones de la aplicación fallen.

Cuando se lanzó Android 6.0 Marshmallow, Google introdujo el atributo de manifiesto android:usesCleartextTraffic como medio de protección contra el uso accidental de tráfico de texto no cifrado. Android 7.0 Nougat amplió este atributo al presentar Android Configuración de seguridad de la red característica, que permite a los desarrolladores ser más prescriptivos sobre las comunicaciones seguras. La configuración de seguridad de la red es un archivo XML en el que los desarrolladores personalizan la configuración de seguridad de la red para una aplicación de Android.

Algunos de ustedes pueden pensar que esto suena familiar. iOS usa una verificación del lado del cliente similar conocida como App Transport Security. Si bien hay bastantes similitudes en las protecciones que ofrece Network Security Configuration en comparación con NSAppTranportSecurity, los dos adoptan enfoques muy diferentes para la seguridad de la red en sus plataformas individuales. Para obtener más información sobre ATS, consulte mi blog anterior.

Examinemos varios beneficios de usar la configuración de seguridad de red en las aplicaciones móviles de Android y profundicemos en las mejores prácticas para implementar esta función.

1. Proteger contra regresiones al tráfico de texto sin cifrar

La seguridad se trata más de capas de protección que de una sola pared de hierro. La función de configuración de seguridad de la red de Android proporciona una capa simple para proteger las aplicaciones de la transmisión involuntaria de datos confidenciales en texto no cifrado.

Si no sabe qué significa «comunicaciones no cifradas», piénselo de esta manera: supongamos que su oficina tiene una política para enviar todos los envíos a través de UPS. Un nuevo pasante se une a la oficina y tiene la tarea de enviar equipos a una oficina en todo el país. Ajeno a la política y con las mejores intenciones, el pasante configura todos los envíos para que se envíen a través de un servicio desconocido y menos costoso. La función de configuración de seguridad de la red de Android es como el administrador de envío/recepción que examina todos los envíos entrantes y salientes y detiene el envío antes de que el equipo llegue a manos de un sistema de entrega no examinado. Se puede utilizar para evitar el uso accidental de conexiones no cifradas que no sean de confianza.

Uno de los mayores cambios en Android 9 es que cleartextTrafficPermitted se establece en false por defecto. Esto significa que si no ve esta marca establecida explícitamente en falso y la aplicación apunta a niveles de API inferiores a 28, la marca se considerará verdadera.

Otra capacidad del cleartextTrafficPermitted bandera que se utiliza en la configuración de seguridad de la red es la capacidad de hacer cumplir la true configuración en dominios y subdominios específicos:

Configuración de seguridad de la red

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

2. Configure autoridades de certificación de confianza para conexiones seguras

Las autoridades de certificación (CA) de confianza actúan como el círculo de confianza. En el ejemplo anterior, la política de la oficina era enviar con UPS, pero esa política podría expandirse a FedEx, DHL, etc. Básicamente, ¿en quién confía para enviar datos de aplicaciones de forma segura y evitar ataques de intermediarios? Los desarrolladores pueden usar la función de configuración de seguridad de red de Android para designar en qué CA confían para emitir certificados y garantizar comunicaciones seguras.

Para empezar, la configuración de seguridad de la red de Android ofrece a los desarrolladores algunas opciones en términos de las CA en las que deberían confiar. De forma predeterminada, el ancla de confianza utilizada por Android 7+ (Nougat, Oreo y Pie) serán los certificados de CA del sistema preinstalados, indicados como system:

Anclajes de confianza: Android 7+

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

En Android 6 (Marshmallow) y versiones anteriores, su configuración predeterminada trust-anchor también incluirá el certificado instalado por el usuario, indicado como user:

Trust Anchors: Android 6 y versiones anteriores

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

Finalmente, puede establecer un ancla de confianza personalizada:

Anclajes de confianza: personalizados

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

3. Implementar la fijación de certificados

La implementación de la fijación de certificados ofrece otra capa de seguridad. Revisemos el ejemplo actual del equipo de envío. Si las CA de confianza son como UPS, FedEx, etc., la fijación de certificados es similar a especificar en cuál de los conductores de esas empresas confía para enviar su envío. La función de configuración de seguridad de red de Android se puede utilizar para restringir las comunicaciones solo con certificados específicos emitidos por una CA de confianza.

Discutimos diferentes implementaciones de fijación de certificados en una publicación de blog anterior. En el siguiente ejemplo, vemos que podemos anclar a un dominio y subdominios específicos, establecer pines junto con copias de seguridad y establecer una fecha de vencimiento.

Fijación de certificados con configuración de seguridad de red

<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. Depurar conexiones de red de aplicaciones

Otra opción que se ofrece en la configuración de seguridad de red de Android es debug-overrides. Esta característica le permite tener configuraciones en la configuración de seguridad de la red que solo se podrán usar cuando android:debuggable se establece en true. Por ejemplo, puede configurar un personalizado trust-anchor para un entorno de control de calidad/preproducción mediante una CA personalizada. Esto facilita las pruebas en un entorno cerrado porque la tienda de aplicaciones no acepta aplicaciones marcadas como depurables.

Anulaciones de depuración

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

Consejos de implementación

Ahora que comprende algunos de los beneficios de implementar la configuración de seguridad de la red, cubramos algunas de las mejores prácticas para implementar este archivo.

Primero, verifique el manifiesto de la aplicación para ver si usa esta función. Busca el atributo android:networkSecurityConfigque sería similar a esto:

Manifiesto de muestra con configuración de seguridad de red

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

Una vez que haya localizado el archivo de configuración de seguridad de la red, es hora de verificar cómo permitir el tráfico de texto no cifrado.

El fragmento de código de ejemplo a continuación muestra un mal ejemplo de cómo alguien podría usar la configuración de seguridad de la red.

Mal ejemplo: permisos de texto sin cifrar con configuración de seguridad de red

<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>

Si bien esto asegura que todo el tráfico a example.com y cdn.example2.com se envía a través de HTTPS, la configuración predeterminada para todo el tráfico enviado a otros dominios puede ser texto simple. Esto anula por completo el propósito previsto de la función Configuración de seguridad de red: mejorar la privacidad de todos los datos transmitidos a través de dispositivos Android.

Si su aplicación móvil debe enviar datos en texto no cifrado, hágalo para permitir solo comunicaciones encriptadas a ciertos dominios. Además, analice detenidamente los puntos finales en los que HTTP tiene permiso explícito para verificar datos confidenciales y otros problemas relacionados con la API:

Implementación recomendada de permisos de texto claro

<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>

Otra cosa a considerar con respecto a la cleartextTrafficPermitted la bandera es por defecto true en Android 8 y versiones anteriores. Debido a esto, establezca explícitamente la bandera en false en la configuración de seguridad de red de todas las aplicaciones.

Veamos otro ejemplo a continuación:

Mal ejemplo: implementación predeterminada de Trust Anchors para Android 6 y versiones anteriores

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

En este ejemplo, vemos que la aplicación está aceptando user certificados dentro del ancla de confianza de la aplicación. Esto significa que la aplicación confiará en los certificados instalados por el usuario de la misma manera que los certificados preinstalados en el sistema. Al configurar el trust-anchors utilizado por la aplicación, es mejor limitar la confianza solo al system certificados y, cuando sea necesario, a una CA personalizada creada dentro de la aplicación. Esto puede ayudar a prevenir ataques MITM en los que un atacante puede instalar un certificado en el dispositivo. Como parte de las protecciones introducidas como parte de Android 7, de manera predeterminada, no se confía en un certificado instalado por el usuario como en los certificados preinstalados. Como se indicó anteriormente, Android 6 y versiones anteriores aceptan user certificados de forma predeterminada, por lo que es importante seleccionar explícitamente system y/o una CA personalizada cuando sea necesario y excluir user en todas las aplicaciones.

Implementación recomendada de anclajes de confianza con CA personalizada (cuando sea necesario)

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

Veamos un ejemplo de implementación de fijación:

Mal ejemplo: fijación de certificados con configuración de seguridad de red

<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>

El ejemplo anterior revela dos problemas potenciales dentro de la aplicación. En primer lugar, no hay un vencimiento establecido para el pin-set. En segundo lugar, no hay pin de respaldo. Una estrategia inteligente es establecer un vencimiento para los certificados y tener varios pines de respaldo. No es extraño tener cuatro pasadores en rotación. Si no establece explícitamente una fecha de caducidad para el PIN, su aplicación no podrá conectarse después de que se produzca la caducidad. Pero si establece una caducidad y el pin caduca, la aplicación conmutará por error a la CA del sistema en el dispositivo en lugar de fallar al conectarse.

Implementación recomendada de asignación de certificados con configuración de seguridad de red

<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>

Finalmente, hablemos de la configuración de seguridad de la red. debug-overrides.

Implementación recomendada de anulaciones de depuración con configuración de seguridad de red

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

Si bien la función de depuración puede ayudar a eliminar el código de red de depuración en una aplicación, asegúrese de eliminar cualquier código de depuración. CA de la aplicación. Como práctica recomendada, evite dejar información innecesaria en su aplicación que podría presentar un riesgo de seguridad, especialmente si los certificados de CA internos se incluyen con la compilación de producción final de la aplicación.

Desde la perspectiva de un analista de seguridad, es importante saber cómo leer y detectar problemas en la configuración de seguridad de la red. Como podemos ver, podemos encontrar algunos problemas potenciales en la aplicación antes de instalarla. Pero tenga en cuenta que estos hallazgos por sí solos no prueban que las conexiones de red de su aplicación sean seguras.

Aún deberá determinar si su aplicación está realizando la verificación del nombre de host, ya que la configuración de seguridad de la red no protegerá contra ese tipo de problemas. Asegúrese de que sus bibliotecas de terceros respeten la configuración de seguridad de la red. Si no lo hacen, estas protecciones pueden causar problemas en su aplicación. Además, la configuración de seguridad de la red no se respeta en las conexiones de red de nivel inferior, como los websockets. Finalmente, tenga en cuenta que los problemas relacionados con la red en dispositivos móviles son solo una pequeña parte del alcance general de las pruebas móviles.

En general, la configuración de seguridad de red de Android ofrece muchas funciones de seguridad de red simples para Android. Si su aplicación actualmente no aprovecha la configuración de seguridad de la red, deberá usarla el próximo año.

Coincidiendo con el lanzamiento de Android P, Google comenzó a aplicar niveles de API objetivo en las tiendas de aplicaciones para reducir la fragmentación del sistema operativo móvil y llevar a los usuarios a las versiones actuales. El requisito actual es 26, aunque Google planea aumentar gradualmente ese número con cada nuevo lanzamiento. Para esta época del próximo año, el nivel 30 de API (Android Q) probablemente estará disponible. Eso significa que si su aplicación usa HTTP, debe declararse en el archivo de configuración de seguridad de la red porque el nivel de API de destino obligatorio será 28 para entonces.

Manténgase al tanto de otras mejoras de seguridad suscribiéndose a nuestro Boletín All Things Mobile DevSecOps y realice pruebas de seguridad de aplicaciones móviles automatizadas para garantizar que sus aplicaciones de Android implementen comunicaciones de red de manera segura.