6 consejos esenciales de seguridad para aplicaciones de Android | Por Gimli Asshiddiqy | Desarrollo de telecomunicaciones | Febrero de 2022


Utilice estos sencillos consejos para mejorar la seguridad de su aplicación Android y ganarse la confianza de sus usuarios
Desarrollar aplicaciones de Android es difícil, pero desarrollar una aplicación de Android segura es aún más difícil. ¿Entonces, para qué molestarse?
Si eres nuevo en el desarrollo de aplicaciones, esto puede no ser de tu interés. Porque tal vez su objetivo actual sea solo crear la mejor y más avanzada aplicación posible.
Pero a medida que continúa aprendiendo, se involucra en un proyecto más grande y desarrolla una aplicación que miles de usuarios usan todos los días… no mejorar la seguridad de la aplicación se vuelve cada vez más peligroso.
No desea crear una aplicación de mil millones de dólares, solo quiere saber que otras personas simplemente están copiando y pegando su trabajo porque saben cómo lo creó.
Además, hay muchas personas que tienen la afición de piratear aplicaciones en Play Store. Ya sea que actúen de buena fe o no, es nuestra responsabilidad evitar que obtengan información para mantener la integridad de la aplicación.
Con eso en mente, ¡veamos qué podemos hacer para mejorar la seguridad de nuestra aplicación!
Tal vez esté familiarizado con el proceso de compilación que convierte el código de su proyecto en un APK instalable que ejecuta su aplicación.Luego, el proceso se puede revertir utilizando la herramienta adecuada para un APK determinado, como JADX Puede obtener el código del proyecto para ese APK… un pocoEste proceso se llama ingeniería inversa.

Bueno, pueden ver el código, ¿y qué? ¿Cuál es el problema? Bueno, su lógica comercial está incrustada en el código. Así que no espere que otros puedan leerlo y seguirlo.
Entonces, ¿cómo resolvemos este problema? Se utiliza la ofuscación, pero ¿qué es exactamente? Este es un proceso que dificulta que los humanos lean y comprendan el código fuente.
Un proyecto de Android que usa R8 y proguard para incrustar herramientas de ofuscación, simplemente configure minifyEnabled
en tu realidad build.gradle
como esto:
De esta forma, se ofuscarán todas las variantes de lanzamiento de su aplicación.
Otra cosa a considerar es configurar proguard, ya que algunas partes deben conservarse y otras están ofuscadas. Por defecto, si no declaras nada, proguard ofuscará todo.
Puede declarar la configuración dentro proguard-rules.pro
documento.
Aquí hay una lista de configuraciones que puede usar:
Esto eskeep
Configuraciones que puedes probar:
Si el APK se descompiló sin ofuscación, se vería así:
Por otro lado, si tiene habilitado ProGuard, se verá así:
Bueno, echará un vistazo… Imagínese, con todo su código, es casi imposible leer cómo funciona su código.
Además de mejorar su seguridad, habilitar proguard puede reducir el tamaño de su aplicación.
Espera, ¿cuál es la diferencia entre esto y la mera ofuscación? Bueno, si puedes mirar el código antes, el efecto de ofuscación es realmente limitado. Por ejemplo, con proguard puedes ofuscar:
- nombre de la clase
- nombre del método/función
- nombre del parámetro
- nombre de la variable
- Nombres de paquetes
Pero hay algo que proguard no puede ofuscar, y ese es el valor de una variable. Aunque el código está ofuscado, aún ejecuta las mismas funciones y algoritmos que antes de la ofuscación… solo que con un nombre diferente. Pero al cambiar el valor de una variable, puede afectar su función, por lo que es bueno que proguard no la ofusque.
Sin embargo, en el valor de la variable, puede almacenar algo importante o confidencial, como la URL base, los puntos finales o incluso las claves API de terceros. Todo lo que no quieres que otros sepan y vean desde tu app.
Entonces, ¿cómo evitamos que otros lean nuestros valores de cadena? Puedo ofrecer dos opciones:
- Usando el NDK, proporcionando nuestras claves como URL base, clave API, etc. en una clase C/C++.La salida de esta clase es
.so
Y es más difícil de descompilar. Leer más aquí:
- Usando StringCare, almacenando la cadena en un archivo de recursos XML y agregando atributos
hidden
a cada etiqueta de valor. Cuando se descompila, la cadena se ofusca, no se puede leer y solo se puede descifrar en tiempo de ejecución. Leer más aquí:
Por lo general, desea que su aplicación se ejecute en un dispositivo real que no haya sido manipulado, como un dispositivo rooteado o un emulador. Porque ejecutarlo en ese dispositivo puede ser peligroso. No tiene restricciones sobre lo que puede hacer su aplicación, y la integridad de los datos de su aplicación puede verse comprometida.
Por lo tanto, es una buena precaución detectar si su aplicación se está ejecutando en un dispositivo o emulador rooteado y manejarlo correctamente.
Hay muchas maneras de determinar estas cosas, pero no lo haga usted mismo… puede usar lo que otros ya han hecho por usted, como:
Por supuesto, no hay una forma de verificar al 100% si un dispositivo está rooteado, pero sigue siendo una buena precaución.
Nos gusta usar SharedPreference para almacenar nuestros valores localmente en el dispositivo, como tokens de acceso o credenciales, etc. Pero si su aplicación puede leerlo, ¿pueden otros? Bueno, sí por defecto.

Almacenar un nuevo valor en SharedPreference hará que cree una nueva etiqueta en el archivo xml dentro del directorio de la aplicación. Este archivo xml se puede abrir y los valores que contiene se pueden usar para hacer cosas malas. Lástima por ti si almacenas tu clave API allí.
Lo que desea hacer es cifrar los nombres y valores de esas SharedPreferences, para que no se pueda usar fuera del alcance de su aplicación.
Aquí hay algunas bibliotecas que pueden hacer esto por usted:
- armadillo una implementación de preferencia compartida para datos confidenciales en Android
- Preferencias compartidas cifradas Envuelve la clase SharedPreferences y encripta automáticamente claves y valores usando métodos de ambos esquemas
Entonces, por ejemplo, antes de usar el cifrado, su SharedPreference se vería así:
Después de usar el cifrado, se ve así:
Ya sea que use SQLite antiguo, Room o incluso Realm… usar una base de datos local es una característica común que los desarrolladores usan en sus aplicaciones. Por ejemplo, si su aplicación admite la funcionalidad fuera de línea, puede almacenar algunos datos en una base de datos local, como transacciones, menús favoritos, etc.
¿Pero es seguro? ¿Pueden otros leer lo que almaceno en mi base de datos local?

Al igual que SharedPreference, puede acceder a la base de datos local en el directorio de la aplicación. Incluso puede llevar la base de datos a su máquina y abrirla con DB Explorer.
Entonces, para evitar que otros lean el contenido de nuestra base de datos, ¡no olvide cifrar su base de datos!
Si está utilizando Room Database o SQLite simple, puede usar sqlcipher hazlo por ti. Aquí hay un código de muestra para hacer esto usando sqlcipcher:
Obligar a todos sus servicios web a admitir HTTP es una buena manera de proteger las conexiones, pero siempre puede hacer más.Incluso con HTTPS, siempre hay amenazas similares intermediario ataque.
Un ataque Man-In-The-Middle básicamente significa cuando un pirata informático pretende ser el servicio al que se está conectando y les permite interceptar la comunicación entre su aplicación y su servicio.
Una de las soluciones a este problema es el pinning de certificados o SSL pinning.Donde verificamos la autenticación del servidor en el lado del cliente (solicitud). Hacer esto en Android es muy simple, aquí hay tres formas de fijar SSL en Android:
TrustManager
que es la forma antigua de usar el mecanismo en el paquete javax.net.ssl- Configuración de seguridad de la red Esta solución funciona en Android API Nivel 24 y superior
- Con Okhttp, si está utilizando Okhttp como su cliente HTTP de Android, en realidad hay una función para anclar su certificado a
Okhttp
clase, así:
Obviamente, todavía hay mucho que puede hacer para mejorar la seguridad de su aplicación de Android. Pero con estos 6 consejos, ¡has tenido un buen comienzo! ¡Seguir aprendiendo!
Obtenga más información sobre lo que puede hacer aquí: