La publicación de las cookies de la semana anterior trajo consigo un debate entre varias amistades mías; unos asegurando que las cookies eran inseguras y poco efectivas y otros defendiéndolas. Por esta razón, creo que vendría bien analizar las alternativas a las mismas para que ustedes se creen un criterio y decidan el lado que van a apoyar ahora que saben un poco más.
Creo que prima empezar aclarando que algunas de las operaciones que se pueden realizar mediante cookies también se pueden hacer mediante otros mecanismos. Pero como es de suponer, estos tienen sus propios inconvenientes (de lo contrario habrían dejado obsoletas a las cookies). Por esta razón la privacidad sigue siendo hasta nuestros días un problema, utilicemos o no las cookies, las defina o no el servidor.
La primera y que seguro se les ha ocurrido a muchos (otros es probable que la hayan leído) es utilizando la dirección IP, que no es más que almacenar esta dirección del ordenador que solicita las páginas. El reconocimiento de IP está disponible desde los inicios de World Wide Web, debido a que es necesario al descargar páginas que el servidor reconozca la dirección IP del ordenador donde corre el navegador. Está opción puede ser guardada en el servidor, esté o no usando cookies. Pero como ustedes sabrán, en algunas redes las direcciones IP son dinámicas (como en Infomed), es decir, se le asignan al ordenador en el momento de conectarse (un mismo ordenador puede tener diferentes direcciones IP en diferentes sesiones). Esto provoca que sea menos fiable que las cookies en la identificación de un usuario. Sin embargo, esta técnica la podemos hacer más confiable si usamos otra característica del protocolo HTTP: en el momento que un usuario solicita una página porque ha seguido un link, la petición que se envía al servidor contiene la URL de la página donde el vínculo estaba localizado. Si el servidor almacena esas URL, se puede rastrear el camino de páginas visitadas por el usuario de forma más precisa. Pero he aquí otro inconveniente: varios usuarios en un mismo ordenador pueden acceder a la misma página y después seguir links diferentes, lo que hace este "rastreo" menos fiable; y digo rastreo porque está técnica sólo permite eso y no puede reemplazar a las cookies en sus otros usos.
Pese a esto, puede que algunos todavía piensen que se puede usar la dirección IP. Pues bien, les diré que es imposible en algunos sistemas que se utilizan precisamente para mantener el anonimato en Internet, tales como Tor (una implementación libre de un sistema de encaminamiento llamado onion routing, que permite a sus usuarios comunicarse en Internet de manera anónima). Con sistemas como este, el navegador utiliza varias direcciones IP a lo largo de una sesión.
Otra técnica más precisa es la URL query string, que consiste en incrustar información en la URL. El mecanismo de sesión de PHP utiliza este método si las cookies no están habilitadas. Consiste en que el servidor web añade query strings a los enlaces de la página web que contiene, a la hora de servirla al navegador. Cuando el usuario sigue un enlace, el navegador devuelve al servidor la query string añadida a los enlaces. Usándolas de esta forma, si nos damos cuenta son muy parecidas a las cookies, siendo ambas porciones de información definidos por el servidor y devueltas por el navegador posteriormente. Pero ahora veamos las diferencias y desventajas de las query strings. Si un usuario accede a una página dos veces, no hay seguridad que utilice la misma query string; tal es el ejemplo siguiente: se accede a una página a través de otra que se encuentre en el mismo servidor y a través de un buscador --> las query string serán normalmente diferentes, mientras las cookies serian iguales. Recordando lo hablado referente a la fijación de sesión (en el artículo cookies de la semana pasada), se puede decir que una query string simplifica dichos ataques, por lo que en esta parte de seguridad las cookies son más seguras (disculpen la redundancia pero la creo necesaria).
Veamos ahora la Autenticación HTTP. Para esta autenticación, el protocolo HTTP incluye mecanismos tales como el Digest Access Authentication, que permite acceder a una página web sólo cuando el usuario ha facilitado un nombre de usuario y contraseña correctos. Después de este acceso el navegador guarda esta información y la utiliza para acceder a las páginas siguientes sin intervención de usuario, para nosotros es lo mismo que las cookies, pero en cada acceso a una página el navegador se encarga de enviar nuevamente estos datos, por lo que si alguien estuviese escuchando este tráfico podría leer esta información y almacenarla para su uso posterior, además de que normalmente tras un tiempo de inactividad estas sesiones expiran.
Ahora pasemos a una alternativa que pocos conocen, y tal es el caso de Objetos Macromedia Flash almacenados localmente. Si un navegador incluye el plug-in de Macromedia Flash Player, se puede utilizar la función Local Shared Objects del mismo, de una forma muy similar a las cookies. El tamaño máximo por defecto de los objetos es de 100 Kb y casi todos los usuarios de Windows tienen Flash Player instalado, de forma que los Local Shared Objects pueden estar habilitados cuando las cookies no lo están. Aquí una alternativa que a mi parecer es de las mejores, aunque existen usuarios novatos en la actualidad que no tienen este plug-in en el navegador.
Otra alternativa -y la última que conozco- es Persistencia en el cliente, que no es más que un mecanismo de persistencia que algunos navegadores web soportan, basado en script que permite que la página almacene información localmente para su uso posterior. Internet Explorer, por ejemplo, soporta información persistente en el historial del navegador, en los favoritos, en un almacenamiento XML, o directamente en una página web guardada en disco.
Black Hat por Email
Black Hat por Feed
No hay comentarios:
Publicar un comentario