Comunicaciones de texto simple

Categoría de OWASP: MASVS-NETWORK: Comunicación de red

Descripción general

Permitir las comunicaciones de red de texto simple en una app para Android implica que cualquier persona que supervise el tráfico de red pueda ver y manipular los datos que se transmiten. Esta es una vulnerabilidad si los datos transmitidos incluyen información sensible, como contraseñas, números de tarjetas de crédito o cualquier otro tipo de información personal.

Independientemente de si envías información sensible o no, usar texto simple puede ser una vulnerabilidad, ya que el tráfico de texto simple también se puede manipular a través de ataques de red, como envenenamiento de ARP o DNS, lo que podría permitir que los atacantes influyan en el comportamiento de una app.

Impacto

Cuando una aplicación para Android envía o recibe datos en texto simple a través de una red, cualquier persona que supervise la red puede interceptarlos y leerlos. Si estos datos incluyen información sensible, como contraseñas, números de tarjetas de crédito o mensajes personales, se pueden producir robos de identidad, fraudes financieros y otros problemas graves.

Por ejemplo, una app que transmite contraseñas en texto simple podría exponer estas credenciales a un actor malicioso que intercepte el tráfico. Esos datos podrían usarse para obtener acceso no autorizado a las cuentas de los usuarios.

Riesgo: Canales de comunicación sin encriptar

La transmisión de datos a través de canales de comunicación sin encriptación expone los datos que se comparten entre el dispositivo y los extremos de la aplicación. Un atacante puede interceptar esos datos y, posiblemente, modificarlos.

Mitigaciones

Los datos deben enviarse a través de canales de comunicación encriptados. Los protocolos seguros deben usarse como alternativa a los protocolos que no ofrecen capacidades de encriptación.

Riesgos específicos

En esta sección, se recopilan los riesgos que requieren estrategias de mitigación no estándar o que se mitigaron en cierto nivel de SDK y están aquí para lograr una integridad.

Riesgo: HTTP

Las instrucciones que se brindan en esta sección solo se aplican a las apps orientadas a Android 8.1 (nivel de API 27) o versiones anteriores. A partir de Android 9 (nivel de API 28), los clientes HTTP, como URLConnection, Cronet y OkHttp, aplican el uso de HTTPS, por lo que la compatibilidad con texto simple está inhabilitada de forma predeterminada. Sin embargo, ten en cuenta que es poco probable que otras bibliotecas cliente HTTP, como Ktor, apliquen estas restricciones en el texto simple y se deben usar con cuidado.

Mitigaciones

Usa la función NetworkSecurityConfig.xml para inhabilitar el tráfico de texto simple y aplicar HTTPS a tu app, con excepciones solo para los dominios específicos requeridos (por lo general, con fines de depuración):

XML

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

Esta opción ayuda a prevenir las regresiones accidentales en apps debido a cambios en URLs que generaron fuentes externas, como servidores backend.

Riesgo: FTP

El uso del protocolo FTP para intercambiar archivos entre dispositivos presenta varios riesgos, el más significativo es la falta de encriptación en el canal de comunicación. En su lugar, se deben usar alternativas más seguras, como SFTP o HTTPS.

Mitigaciones

Cuando implementes mecanismos de intercambio de datos a través de Internet en tu aplicación, debes usar un protocolo seguro, como HTTPS. Android pone a disposición un conjunto de APIs que permiten a los desarrolladores crear una lógica de cliente-servidor. Esto se puede proteger con la seguridad de la capa de transporte (TLS), lo que garantiza que el intercambio de datos entre dos extremos esté encriptado y, por lo tanto, evita que los usuarios maliciosos espíen las comunicaciones y recuperen datos sensibles.

Por lo general, las arquitecturas cliente-servidor dependen de las APIs que pertenecen a los desarrolladores. Si tu aplicación depende de un conjunto de extremos de API, sigue estas prácticas recomendadas de seguridad para proteger las comunicaciones HTTPS y garantizar la seguridad en profundidad:

  • Autenticación: Los usuarios deben autenticarse con mecanismos seguros, como OAuth 2.0. Por lo general, no se recomienda la autenticación básica, ya que no proporciona mecanismos de administración de sesiones y, si las credenciales se almacenan de forma inadecuada, se pueden decodificar desde Base64.
  • Autorización: Se debe restringir el acceso de los usuarios solo a los recursos previstos según el principio de privilegio mínimo. Esto se puede implementar mediante la adopción de soluciones de control de acceso cuidadosas para los recursos de la aplicación.
  • Asegúrate de usar conjuntos de algoritmos de cifrado más recientes y bien pensados, siguiendo las prácticas recomendadas de seguridad. Por ejemplo, considera admitir el protocolo TLSv1.3 con retrocompatibilidad, si es necesario, para las comunicaciones HTTPS.

Riesgo: Protocolos de comunicación personalizados

Implementar protocolos de comunicación personalizados o intentar implementar manualmente los conocidos puede ser peligroso.

Si bien los protocolos personalizados permiten a los desarrolladores adaptar una solución única que se adapte a las necesidades previstas, cualquier error durante el proceso de desarrollo puede generar vulnerabilidades de seguridad. Por ejemplo, los errores en el desarrollo de mecanismos de manejo de sesiones pueden hacer que los atacantes puedan escuchar las comunicaciones y recuperar información sensible sobre la marcha.

Por otro lado, implementar protocolos conocidos, como HTTPS, sin usar un SO o bibliotecas de terceros bien mantenidas, aumenta la probabilidad de introducir errores de codificación que pueden dificultar, o incluso imposibilitar, la actualización del protocolo que implementaste cuando sea necesario. Además, esto puede introducir el mismo tipo de vulnerabilidades de seguridad que el uso de protocolos personalizados.

Mitigaciones

Usa bibliotecas mantenidas para implementar protocolos de comunicación conocidos

Para implementar protocolos conocidos, como HTTPS, en tu aplicación, se deben usar bibliotecas del SO o bibliotecas de terceros mantenidas.

Esto les brinda a los desarrolladores la seguridad de optar por soluciones que se probaron en detalle, se mejoraron con el tiempo y reciben actualizaciones de seguridad de forma continua para corregir vulnerabilidades comunes.

Además, cuando los desarrolladores optan por protocolos conocidos, se benefician de una amplia compatibilidad con varios sistemas, plataformas y IDE, lo que reduce la probabilidad de errores humanos durante el proceso de desarrollo.

Usa SFTP

Este protocolo encripta los datos en tránsito. Se deben tener en cuenta medidas adicionales cuando se usa este tipo de protocolo de intercambio de archivos:

  • SFTP admite diferentes tipos de autenticación. En lugar de la autenticación basada en contraseñas, se debe usar el método de autenticación de clave pública. Estas claves deben crearse y almacenarse de forma segura. Para ello, se recomienda Android Keystore.
  • Asegúrate de que los algoritmos de cifrado admitidos sigan las prácticas recomendadas de seguridad.

Recursos