Cuando tu aplicación se comunica con servidores que usan tráfico de red de Cleartext, como en el caso del HTTP, este tráfico corre el riesgo de ser interceptado y manipulado por terceros. Esto puede producir fugas de información sobre tus usuarios y dejar tu aplicación expuesta al ingreso de contenidos no autorizados o al aprovechamiento de vulnerabilidades. Lo ideal sería que tu aplicación usara únicamente tráfico seguro; por ejemplo, el protocolo
HTTPS en lugar del HTTP. Este tipo de tráfico cuenta con protección contra la intercepción y la manipulación.
Muchas aplicaciones de Android ya usan exclusivamente el tráfico seguro. Sin embargo, en algunas de ellas de tanto en tanto se producen regresiones a tráfico de Cleartext por accidente. Por ejemplo, un cambio inadvertido en uno de los componentes del servidor podría hacer que este proporcione a la aplicación URL HTTP en lugar de HTTPS. En este caso, la aplicación establecerá comunicaciones mediante tráfico de Cleartext, sin señales visibles para el usuario. Esta situación puede pasar inadvertida para el desarrollador y los usuarios de la aplicación.
Aun cuando creas que tu aplicación solo usa tráfico seguro, asegúrate de usar los nuevos mecanismos que ofrece Android Marshmallow (Android 6.0) para detectar y evitar regresiones accidentales.
NUEVOS MECANISMOS DE PROTECCIÓN
Para las aplicaciones que usan exclusivamente tráfico seguro, en Android 6.0 Marshmallow (nivel de API 23) se presentaron dos mecanismos que permiten abordar las regresiones a tráfico de Cleartext: (1) en producción o base instalada, bloqueo del tráfico de Cleartext, y (2) durante el desarrollo o control de calidad (QA), registro o bloqueo ante casos de tráfico TLS/SSL. En las secciones siguientes se proporciona más información acerca de estos mecanismos.
Bloqueo del tráfico de Cleartext en producción
Para proteger la base instalada de tu aplicación contra regresiones a tráfico de Cleartext, declara el atributo
android:usesCleartextTraffic=”false” en el elemento
application del
AndroidManifest.xml de tu aplicación. Con esto se declara que la aplicación no debe usar el tráfico de la red de Cleartext y que las pilas de red de plataforma de Android Marshmallow bloquean el tráfico de Cleartext de la aplicación. Por ejemplo, si tu aplicación intenta accidentalmente iniciar la sesión del usuario a través de una solicitud HTTP de Cleartext, esta solicitud se bloqueará y la identidad y contraseña del usuario no se fugarán hacia la red.
No es necesario que fijes
minSdkVersion o targetSdkVersion en 23 en tu aplicación (Android Marshmallow) para usar
android:usesCleartextTraffic. En plataformas previas, este atributo simplemente se ignora y no tiene efecto.
Ten en cuenta que
WebView aún no respeta esta función.
A su vez, en determinadas circunstancias es posible que se produzcan entradas o salidas en la aplicación a través del tráfico de Cleartext. Por ejemplo, la API de Socket ignora la política de Cleartext porque no determina si los datos que transmite o recibe pueden clasificarse como Cleartext. Por otra parte, las pilas HTTP de la plataforma de Android respetan la política porque pueden determinar si el tráfico es de Cleartext.
Google AdMob también está preparado para respetar esta política. Cuando tu aplicación declara que no usa tráfico de Cleartext, solo se deben proporcionar a esta los anuncios exclusivos de HTTPS.
Se sugiere agregar compatibilidad con esta política a bibliotecas de redes, anuncios y análisis de terceros. Estas pueden realizar consultas en la política de tráfico de Cleartext a través de la clase
NetworkSecurityPolicy.
Detección de tráfico de Cleartext durante el desarrollo
Para identificar tráfico de Cleartext durante el desarrollo o el QA, la
API de StrictMode te permite modificar tu aplicación a fin de detectar tráfico que no sea TLS ni SSL y luego registrar violaciones en el registro del sistema o bloquear la aplicación (consulta
StrictMode.VmPolicy.Builder.detectCleartextNetwork()). Esta herramienta resulta útil para identificar los componentes de la aplicación que usan tráfico TLS o SSL (y DLTS). A diferencia del atributo
android:usesCleartextTraffic, esta función no está pensada para habilitarse en compilaciones de aplicaciones distribuidas a usuarios.
En primer lugar, su propósito es marcar tráfico seguro que no sea TLS ni SSL. Lo que es más importante, también es posible que se marque tráfico TLS o SSL a través de un proxy HTTP. Esto representa un problema, ya que como desarrollador no tienes control sobre el hecho de que un usuario determinado de tu aplicación pueda haber configurado su dispositivo Android para usar un proxy HTTP. Por último, la implementación de la función no está preparada en términos de proyección hacia el futuro y puede rechazar versiones futuras del protocolo TLS o SSL. Por lo tanto, esta función está pensada para usarse únicamente durante la etapa de desarrollo y QA.
Declaración de políticas de Cleartext más refinadas en la configuración de seguridad de la red
Android N ofrece un control más refinado para la política de tráfico de Cleartext. A diferencia del atributoandroid:usesCleartextTraffic, que se aplica a todos los destinos con los cuales se comunica una aplicación, la
configuración de seguridad de red de Android N permite que una aplicación especifique la política de Cleartext para destinos determinados. Por ejemplo, a fin de facilitar una transición más gradual hacia una política que no permita el tráfico de Cleartext, una aplicación puede, al principio, bloquear el uso accidental de tráfico Cleartext solo para la comunicación con sus backends más importantes y permitir el uso de Cleartext para otros destinos.
PRÓXIMOS PASOS
El uso exclusivo de tráfico de red seguro para la comunicación entre tu aplicación y sus servidores representa una práctica recomendada de seguridad. Android Marshmallow te permite implementar esta práctica. ¡Pruébala!
Como siempre, apreciamos los comentarios y recibimos con gusto sugerencias para mejorar Android. Escríbenos a
security@android.com. HTTPS; Seguridad de Android
