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 y modificar esos datos.
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 para 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 roben información de 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 una seguridad integral:
- 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 tratar de implementar protocolos conocidos de forma manual, 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 control de sesiones pueden hacer que los atacantes puedan espiar las comunicaciones y recuperar información sensible sobre la marcha.
Por otro lado, implementar protocolos conocidos, como HTTPS, sin usar el SO o bibliotecas de terceros bien mantenidas, aumenta la probabilidad de introducir errores de codificación que pueden dificultar, o incluso imposibilitar, actualizar el protocolo que implementaste cuando sea necesario. Además, esto puede introducir el mismo tipo de vulnerabilidades de seguridad que usar 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 de forma exhaustiva, se mejoraron con el tiempo y reciben actualizaciones de seguridad de forma continua para corregir vulnerabilidades comunes.
Además, si optan por protocolos conocidos, los desarrolladores se benefician de una amplia compatibilidad entre varios sistemas, IDE y plataformas, 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ña, 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
- Ktor
- Cómo realizar operaciones de red con Cronet
- OkHttp
- Inhabilitación de tráfico de texto simple para la configuración de seguridad de la red
- Cómo conectarse a la red
- Seguridad con protocolos de red
- OAuth 2.0 para aplicaciones de escritorio y dispositivos móviles
- HTTP a través de RFC de TLS
- Esquemas de autenticación de HTTP
- Recomendaciones de seguridad web de Mozilla
- Generador de configuración recomendada de SSL de Mozilla
- Recomendaciones de TLS del servidor de Mozilla
- Página principal del manual de OpenSSH
- RFC de SSH, que detalla las configuraciones y los esquemas que se pueden usar para este protocolo
- Recomendaciones de seguridad de OpenSSH de Mozilla
- Sistema Android Keystore