Blog

HTML5 LocalStorage análisis y riesgos

banner_html5

Con la llegada de HTML5 a nuestras vidas se abrió un abanico de posibilidades para los desarrolladores frontend que hacían su vida mas fácil. Una de estas nuevas features es LocalStorage (o Web Storage) y SessionStorage, como podéis suponer se trata de una suerte de sistema de almacenamiento que proporciona al desarrollador entre 2-10MB de espacio para utilizar.

A grandes rasgos las principales características son:

  • Entre 2-10MB por subdominio (El tamaño depende de la implementación del navegador).
  • Los datos solo se pueden almacenar como texto (string).
  • Los datos almacenados se guardan en el sistema en un archivo SQLite que contiene los datos en texto plano.

Muchas personas vieron en la llegada de LocalStorage el fin de las cookies y de hecho una simple búsqueda nos devuelve multitud de sitios que nos recomiendan el uso de localStorage. No obstante esta tecnología no está pensada para utilizar en sistemas de autenticación o almacenar información sensible. Como veremos a continuación su uso se debe limitar a sistemas de caché e información no sensible para el funcionamiento de la aplicación.

Vectores de ataque

Acceso físico:

Como ya hemos dicho cuando se hace uso de localStorage el navegador crea un archivo en el sistema que se almacena de forma permanente hasta que el usuario lo elimina manualmente. Este archivo puede ser accedido por cualquier persona con acceso físico a la máquina del usuario o donde se haya ejecutado la aplicación.

Por ejemplo para Google Chrome en un entorno Windows7 la ruta del archivo es:

C:\Users\[USERNAME]\AppData\Local\Google\Chrome\User Data\Default\Local Storage

Como prueba utilizaremos uno de los muchos ejemplos de aplicaciones que usan localstorage, los archivos creados tienen la siguiente estructura:  http[s]_www.dominio.com_0.localstorage y pueden ser abiertos con un editor SQLite.

En nuestro caso:

OpenFile

Ademas de permitir acceso directo a los datos este archivo es creado cada vez que se abre la aplicación web en un navegador distinto por lo que si dicha aplicación almacenase en localstorage datos privados del usuario y éste utilizase la aplicación en un ordenador público o de un tercero esos datos quedarían clonados en el disco, esparciendo esos datos confidenciales por todos los ordenadores y/o dispositivos donde se utilizase.

Cross Site Scripting:

Haciendo uso de un XSS de cualquier tipo un atacante puede volcar todo el contenido de localstorage en segundos lo que combinado al caso anterior de una aplicación que almacene información sensible, puede dar lugar a una situación peligrosa.

Un payload que explote localstorage sería:

if(localstorage.lenght){
	for( item in localstorage){
		ls_items += "[" + item + "|" + localstorage.getItem(item) + "]";
	}
}

Y tras recolectar todos los items de localstorage enviariamos ls_items a nuestro servidor.

DNS Spoofing:

La verificación para acceder a Local Storage desde el navegador se basa únicamente en el dominio que el navegador reciba por lo que un atacante puede engañar al navegador de la víctima remotamente falseando el servidor DNS y sirviendo una página maliciosa a la víctima que extraiga todos los datos de Local Storage del mismo modo que vimos con el XSS.

Para simplificar el ejemplo editamos el archivo hosts redireccionando www.lewebmonster.com a nuestro servidor local que simplemente nos mostrará el contenido de todo lo almacenado en localstorage por pantalla:

hosts

Por último solamente tenemos que acceder a la web y nuestro servidor estará mostrando los datos de un dominio que nosotros hemos forzado:

Sin título

Como veis el navegador simplemente valida el dominio y nos carga el archivo http_www.lewebmonster.com_0.localstorage asociado a él sin ninguna validación adicional por lo que la extracción de estos datos de manera remota es viable en diversos escenarios:

  • DNS Spoofing
  • Rogue DNS
  • Rogue Proxy
  • Modificación de archivos hosts

Conclusión:

Como hemos visto el uso de localStorage para almacenar información sensible es peligrosa y se debe evitar. A diferencia de las cookies localStorage carece de flags como httponly o cualquier tipo de seguridad por lo que almacenar cualquier tipo de identificadores de session puede comprometer al usuario.

En OWASP.org podéis echar un vistazo a las recomendaciones de uso y auditoría: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage

En el caso de que algún dia os toque auditar una aplicación web prestad atención a este tipo de usos, ya que de utilizar una mala implementación se podría estar filtrando información privada en el disco duro de los usuarios por cada ejecución de la aplicación.

Adrián – adrian@highsec.es – @shellshocklabs

  1. Cali Rojas
    Cali Rojas12-26-2013

    Hola Adrián, muy interesante su análisis. Gracias por compartir 🙂

Leave a Reply

*

    No Twitter Messages