Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Security
Code

Asegurando las comunicaciones en Android

by
Difficulty:BeginnerLength:MediumLanguages:

Spanish (Español) translation by Luis Chiabrera (you can also view the original English article)

Con todas las violaciones de datos recientes, la privacidad se ha convertido en un tema importante. Casi todas las aplicaciones se comunican a través de la red, por lo que es importante considerar la seguridad de la información del usuario. En esta publicación, conocerá las mejores prácticas actuales para proteger las comunicaciones de su aplicación de Android.

Utilizar HTTPS

A medida que desarrolla su aplicación, es una buena práctica limitar sus solicitudes de red a aquellas que son esenciales. Para los más importantes, asegúrese de que estén hechos a través de HTTPS en lugar de HTTP. HTTPS es un protocolo que encripta el tráfico para que no pueda ser interceptado fácilmente por los espías. Lo bueno de Android es que la migración es tan simple como cambiar la URL de http a https.

De hecho, las versiones de Android N y superiores pueden imponer HTTPS utilizando la configuración de seguridad de red de Android.

En Android Studio, seleccione el directorio app / res / xml para su proyecto. Crea el directorio xml si aún no existe. Selecciónelo y haga clic en Archivo> Nuevo archivo. Llámelo network_security_config.xml. El formato para el archivo es el siguiente:

Para decirle a Android que use este archivo, agregue el nombre del archivo a la etiqueta de la aplicación en el archivo AndroidManifest.xml:

Actualizar proveedores criptográficos

El protocolo HTTPS ha sido explotado varias veces a lo largo de los años. Cuando los investigadores de seguridad reportan vulnerabilidades, los defectos suelen ser parcheados. La aplicación de los parches garantiza que las conexiones de red de su aplicación estén utilizando los protocolos estándar del sector más actualizados. Las versiones más recientes de los protocolos contienen menos debilidades que las anteriores.

Para actualizar los proveedores criptográficos, deberá incluir los servicios de Google Play. En su archivo de módulo de build.gradle, agregue la siguiente línea a la sección de dependencias:

La API de servicios de SafetyNet tiene muchas más funciones, incluida la API de navegación segura que comprueba las URL para ver si han sido marcadas como una amenaza conocida, y una API reCAPTCHA para proteger su aplicación de spammers y otro tráfico malicioso.

Después de sincronizar Gradle, puede llamar al método installIfNeededAsync del ProviderInstaller:

Se llama al método onProviderInstalled () cuando el proveedor se actualiza correctamente o ya está actualizado. De lo contrario, se llama a onProviderInstallFailed (int errorCode, Intent recoveryIntent).

Certificado y establecimiento de claves públicas

Cuando realiza una conexión HTTPS a un servidor, el servidor presenta un certificado digital y lo valida Android para asegurarse de que la conexión sea segura. El certificado puede firmarse con un certificado de una autoridad de certificación intermedia. Este certificado utilizado por la autoridad intermedia podría a su vez estar firmado por otra autoridad intermedia, y así sucesivamente, lo que es confiable siempre que el último certificado esté firmado por una autoridad de certificación raíz en la que ya sea confiable el sistema operativo Android.

Si alguno de los certificados en la cadena de confianza no es válido, entonces la conexión no es segura. Si bien este es un buen sistema, no es infalible. Es posible que un atacante indique al sistema operativo Android que acepte certificados personalizados. Los proxies de intercepción pueden poseer un certificado de confianza, y si el dispositivo está controlado por una empresa, es posible que la empresa haya configurado el dispositivo para que acepte su propio certificado. Estos escenarios permiten un ataque de "hombre en el medio", lo que permite descifrar y leer el tráfico HTTPS.

La fijación de certificados llega al rescate al verificar el certificado del servidor que se presenta contra una copia del certificado esperado. Esto evita que se realicen conexiones cuando el certificado es diferente del esperado.

Para implementar el anclaje en Android N y superior, debe agregar un hash (llamado pasadores) del certificado en el archivo network_security_config.xml. Aquí hay una implementación de ejemplo:

Para encontrar los pines de un sitio específico, puede ir a SSL Labs, ingresar al sitio y hacer clic en Enviar. O, si está desarrollando una aplicación para una empresa, puede solicitarla a la empresa.

Nota: Si necesita admitir dispositivos que ejecuten una versión de SO anterior a Android N, puede usar la biblioteca TrustKit. Utiliza el archivo de configuración de seguridad de red exactamente de la misma manera.

Desinfección y Validación

Con todas las protecciones hasta ahora, sus conexiones deben ser bastante seguras. Aun así, no te olvides de la validación de programación regular. Los datos confiados a ciegas recibidos de la red no son seguros. Una buena práctica de programación es el "diseño por contrato", donde las entradas y salidas de sus métodos satisfacen un contrato que define expectativas de interfaz específicas.

Por ejemplo, si su servidor espera una cadena de 48 caracteres o menos, asegúrese de que la interfaz solo devolverá hasta 48 caracteres inclusive.

Si solo está esperando números del servidor, sus entradas deben verificar esto. Si bien esto ayuda a prevenir errores inocentes, también reduce la probabilidad de ataques de corrupción de memoria e inyección. Esto es especialmente cierto cuando esos datos se pasan a NDK o JNI, código C y C ++ nativo.

Lo mismo ocurre con el envío de datos al servidor. No envíe datos a ciegas, especialmente si son generados por el usuario. Por ejemplo, es una buena práctica limitar la duración de la entrada del usuario, especialmente si será ejecutada por un servidor SQL o cualquier tecnología que ejecutará código.

Si bien proteger a un servidor contra ataques está fuera del alcance de este artículo, como desarrollador móvil, puede hacer su parte eliminando los caracteres del idioma que usa el servidor. De esa manera, la entrada no es susceptible a ataques de inyección. Algunos ejemplos son quitar comillas, puntos y comas y barras cuando no son esenciales para la entrada del usuario:

Si sabe exactamente el formato que se espera, debe verificarlo. Un buen ejemplo es la validación de correo electrónico:

Los archivos pueden ser revisados también. Si está enviando una foto a su servidor, puede verificar que sea una foto válida. Los dos primeros bytes y los dos últimos bytes son siempre FF D8 y FF D9 para el formato JPEG.

Tenga cuidado al mostrar una alerta de error que muestre directamente un mensaje del servidor. Los mensajes de error pueden revelar información privada de depuración o relacionada con la seguridad. La solución es que el servidor envíe un código de error que el cliente busca para mostrar un mensaje predefinido.

Comunicación con otras aplicaciones

Mientras protege la comunicación hacia y desde el dispositivo, también es importante proteger IPC. Ha habido casos en que los desarrolladores han dejado archivos compartidos o han implementado sockets para intercambiar información confidencial. Esto no es seguro. Es mejor usar intenciones. Puede enviar datos utilizando una Intención proporcionando el nombre del paquete de esta manera:

Para transmitir datos a más de una aplicación, debe hacer cumplir que solo las aplicaciones firmadas con su clave de firma obtendrán los datos. De lo contrario, la información que envíe puede ser leída por cualquier aplicación que se registre para recibir la transmisión. Del mismo modo, una aplicación maliciosa puede enviar una transmisión a su aplicación si se ha registrado para recibir la transmisión. Puede usar un permiso al enviar y recibir transmisiones donde la firma se utiliza como nivel de protección. Puede definir un permiso personalizado en el archivo de manifiesto como este:

Entonces puedes otorgar el permiso así:

Ambas aplicaciones necesitan tener los permisos en el archivo de manifiesto para que funcione. Para enviar la transmisión:

Alternativamente, puede usar setPackage (String) cuando envíe una transmisión para restringirla a un conjunto de aplicaciones que coincidan con el paquete especificado. La configuración de android:exported a falso en el archivo de manifiesto excluirá las transmisiones que se reciban desde fuera de su aplicación.

Encriptado de fin a fin

Es importante comprender los límites de HTTPS para proteger las comunicaciones de red. En la mayoría de las implementaciones de HTTPS, el cifrado termina en el servidor. Por ejemplo, su conexión al servidor de una corporación puede ser a través de HTTPS, pero una vez que el tráfico llega al servidor, no está encriptado. Luego se puede reenviar a otros servidores, ya sea estableciendo otra sesión HTTPS o enviándola sin cifrar. La corporación puede ver la información que se ha enviado y, en la mayoría de los casos, es un requisito para las operaciones comerciales. Sin embargo, también significa que la compañía podría pasar la información a terceros sin cifrar.

Hay una tendencia reciente llamada "encriptación de extremo a extremo" en la que solo los dos dispositivos de comunicación pueden leer el tráfico. Un buen ejemplo es una aplicación de chat cifrada en la que dos dispositivos móviles se comunican entre sí a través de un servidor; solo el remitente y el destinatario pueden leer los mensajes del otro.

Una analogía para ayudarlo a comprender el cifrado de extremo a extremo es imaginar que desea que alguien le envíe un mensaje que solo usted puede leer. Para hacer esto, les proporciona una caja con un candado abierto (la clave pública) mientras mantiene la llave del candado (clave privada). El usuario escribe un mensaje, lo coloca en el cuadro, bloquea el candado y se lo envía a usted. Solo tú puedes leer el mensaje porque eres el único con la llave para desbloquear el candado.

Con el cifrado de extremo a extremo, ambos usuarios se envían mutuamente sus claves. El servidor solo proporciona un servicio para la comunicación, pero no puede leer el contenido de la comunicación. Si bien los detalles de la implementación están fuera del alcance de este artículo, es una tecnología poderosa. Si desea obtener más información sobre este enfoque, un buen lugar para comenzar es el repositorio de GitHub para el proyecto Signal de código abierto.

Conclusión

Con todas las nuevas leyes de privacidad, como GDPR, la seguridad es cada vez más importante. A menudo es un aspecto descuidado del desarrollo de aplicaciones móviles.

En este tutorial, ha cubierto las mejores prácticas de seguridad, incluido el uso de HTTPS, el establecimiento de certificados, el saneamiento de datos y el cifrado de extremo a extremo. Estas mejores prácticas deberían servir como base para la seguridad al desarrollar su aplicación móvil. Si tiene alguna pregunta, no dude en dejarla a continuación, y mientras esté aquí, ¡vea algunos de mis otros tutoriales sobre la seguridad de la aplicación Android!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.