Inicio » Android » Shared Preferences y SQLite en Android ¿Seguridad? (I de III)

Shared Preferences y SQLite en Android ¿Seguridad? (I de III)

Antes de empezar con estas entradas me gustaría dejar claro que en ningún momento se debería usar esta información para realizar ninguna acción ilegal, como modificar fechas de expiración de aplicaciones, leer datos privados ni obtener claves de seguridad privadas de terceros. Publico estas entradas sólo con el ánimo de enseñar los problemas de seguridad que nos pueden traer asociados el desarrollar nuestras aplicaciones con un método de almacenamiento de datos determinado y el poco cuidado que ponen ciertos desarrolladores de aplicaciones a la hora de tratar datos tan sensibles como las claves públicas y privadas de nuestro servicio de almacenamiento en la nube “supuestamente” seguro, o el crear un sistema de licenciamiento de aplicaciones basado en almacenar la fecha de expiración en el propio dispositivo en lugar de hacerlo en servidores en la nube del propio desarrollador o con algún método más eficaz, como cifrando de algún modo dichos datos.

Hecha esta aclaración, insisto en que cada uno es responsable de la aplicación que le dé a esta información y que quede constancia de que puede estar incurriendo en acciones ilegales.

Siguiendo con las entradas de dicadas a Android, esta vez os voy a hablar de las “Shared Preferences”.

Ya os dejé claro en el primer post sobre Android, que no soy ningún experto en el tema, así que podéis encontrar alguna información que sea incorrecta. Agradeceré cualquier comentario al respecto para hacer la entrada lo más fiable posible.

Cuando desarrollamos una aplicación en Android, tenemos distintas maneras de almacenar la información que nuestra aplicación necesita. Según la guía de desarrolladores de Android, las opciones que tenemos son las siguientes:

  • Shared Preferences: Almacenamiento privado en parejas “clave-valor”.
  • Almacenamiento Interno: Almacenar los datos privados en la memoria del dispositivo.
  • Almacenamiento Externo: Almacenar los datos públicos en el almacenamiento externo.
  • SQLite: Almacenar los datos en una base de datos SQLite privada.
  • Conexión de Red: Almacenar los datos en una web o nube en nuestro propio servidor.

Si utilizamos “Shared Preferences” en nuestra aplicación, las parejas clave-valor serán almacenadas en un archivo XML dentro de nuestro dispositivo, pudiendo elegir al desarrollar la aplicación si el archivo será accesible sólo por nuestra aplicación o puede ser accedido también por otras aplicaciones y compartir los datos.

El problema de seguridad que se nos presenta con éste método es, que siendo “root” del dispositivo, podemos tener acceso a dichos archivos XML de las aplicaciones y poder leer y modificar los datos almacenados en ellos. A simple vista no parece un fallo grave de seguridad, pero si lo analizamos más profundamente nos daremos cuenta de que podemos modificar, por ejemplo, una fecha de expiración de una aplicación que un desarrollador descuidado ha guardado ahí sin cifrar u ofuscar de algún modo, leer los mensajes de WhatsApp almacenados en la base de datos SQLite del dispositivo (sí, eso que todo el mundo pregunta cómo se puede hacer) y acceder a los archivos multimedia guardados en los servidores de WhatsApp (ya que tenemos las rutas URL de cada unos de los archivos enviados y recibidos en dicha base de datos SQLite), así como sacar claves públicas y privadas de Mega, por ejemplo (esas que te permiten descifrar cualquier archivo de Mega que te pertenezca y cifrarlos como si fuesen tuyos) que se quedan almacenadas en el archivo XML en texto plano. ¿Tal vez activar una opción de una aplicación que sólo es accesible desde la versión de pago? Si está almacenada en las Shared Preferences, tal vez sólo hay que sustituir un “false” por un “true” para que esté accesible para nosotros también…

En esta primera entrada sobre “Shared Preferences” nos centraremos en explicar el funcionamiento de una de las muchas aplicaciones que nos permiten acceder a los datos y cómo podemos modificarlos de una manera muy sencilla. La aplicación se llama “Hack App Data” de SteelWorks, disponible gratuitamente desde Play Store.

La necesidad de ser “root” del dispositivo es porque a priori, los archivos están almacenados dentro de las carpetas de sistema, y no son accesibles por exploradores que no tengan permisos de superusuario (otra excusa más para probar a rootear nuestro dispositivo).

Si somos “root”, no hace falta ni siquiera buscar el archivo y exportarlo a un PC, ya que con las citadas aplicaciones podemos acceder desde el propio dispositivo a todos los archivos XML de todas las aplicaciones que tenemos instaladas (tanto aplicaciones de Usuario como aplicaciones de Sistema)  y modificar sus valores directamente.

Una vez instalada y ejecutada dicha aplicación, nos aparece una pantalla donde podemos elegir de qué tipo de aplicaciones queremos mostrar los archivos XML. Podemos escoger entre aplicaciones de usuario o aplicaciones de sistema.

imagen1 imagen2 imagen3

Dentro de las aplicaciones de sistema encontraremos el calendario, la propia Play Store, Gmail, Contactos, Aplicación de Teléfono, Galería… y todas las aplicaciones que vienen integradas en el sistema operativo del teléfono o tableta.

Si optamos por las aplicaciones de usuario, encontraremos todas las aplicaciones que hayamos descargado e instalado que no forman parte del propio sistema operativo.

Seleccionamos una de las aplicaciones pulsando sobre ella y nos aparecerá una nueva pantalla con los datos básicos de la aplicación: nombre, nombre del paquete instalado, tamaño, fecha de instalación…

imagen4 imagen5 imagen6

Seleccionando el botón “Preference” que se encuentra al pie de la pantalla, podremos ver todos los registros que almacena la aplicación en las citadas “Shared Preferences”.

Si seleccionamos el botón “Database” y la aplicación tiene una base de datos SQLite donde almacenar datos, nos aparecerá una pantalla con todas las bases de datos que utiliza.

Seleccionando una base de datos concreta, nos aparecerá una nueva pantalla con las tablas que contiene dicha base de datos, y seleccionando una tabla, nos aparecerán los registro propiamente dichos.

imagen8 imagen9

Comentar que los registros de la base de datos SQLite no son editables desde esta aplicación, pero podemos encontrar muchas gratuitas en el propio Play Store que nos permiten gestionar las bases de datos de este tipo.

Y pasamos a la parte que nos ocupa en esta entrada del blog, seleccionar las “Shared Preferences”.

Desde esta pantalla sí que podremos pulsar sobre una pareja clave-valor y editar su contenido, pudiendo guardarlo directamente en el dispositivo.

imagen7 imagen10

Sólo habría que pulsar sobre el botón “Save” para que los cambios se guardasen en el archivo en cuestión, y que la aplicación en la siguiente ejecución tomase el nuevo valor editado.

¿Y si cambiamos el valor de una pareja clave-valor almacenada que se llama “expiry” y tiene por valor 1397656370 (Epoch Time Linux)? ¿Si cambiamos el primer 1 por un 5 por ejemplo? Podéis probar por vosotros mismos pero probablemente la aplicación en lugar de “expirar” en 2014, expiraría en 2141.

Hasta la próxima, saludos.


Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.