¿Qué son y cómo funcionan las cookies?

Ramón Saquete

Escrito por Ramón Saquete

¿Qué son y cómo funcionan las cookies?

cookie-monsterUna cookie o galleta informática es un pequeño archivo con información que se almacena en el navegador del usuario cuando visita un sitio web y en el que se suelen guardar las configuraciones y preferencias del usuario o el estado de la sesión de navegación como, por ejemplo, si está logueado o no, o los productos que ha añadido a su carrito de la compra.

Últimamente se habla mucho de las cookies debido a la aparición de la ley anticookies, pero son pocos los que entienden realmente qué son y cómo funcionan. Veamos en qué consisten:

Los archivos que forman las webs viajan a través de las redes encapsulados dentro de paquetes de información que usan el protocolo HTTP (Hypertext Transfer Protocol).  Este protocolo se dice que es sin estado porque no tiene forma de guardar éste entre distintas peticiones. Algunos ejemplos de estados pueden ser: tener la sesión abierta,  si no es la primera visita al sitio, tener un producto en el carrito de la compra, etc. Una de las formas de mantener el estado  y, por lo tanto, de permitir que el contenido de una misma URL cambie según las acciones del usuario, son las cookies.

Una cookie está formada por una clave que le da nombre y un valor asociado, que se puede crear, modificar o borrar tanto en el cliente como en el servidor y que una vez creada se envía en cada petición HTTP, de cada archivo, como parámetro de este protocolo. El nombre de cookies se deriva del término informático magic cookie, que define a la información que se envía y se devuelve igual en cada petición.

Por ejemplo, podemos tener una cookie cuya clave sea “carrito” con el valor “12345”, que indica que la web tiene que mostrar el carrito con identificador “12345”. Este carrito tendrá los productos que ha elegido el usuario para su posterior compra.

¿Cómo funcionan las cookies?

Las cookies pueden ser persistentes o no persistentes. Son persistentes, si tienen un tiempo de expiración y si no lo tienen, se borran en el momento en que se cierra el navegador. Las cookies no persistentes son las que se usan para mantener abierta la sesión del usuario, ya que el servidor sabe por el identificador de la cookie a qué usuario pertenece cada sesión abierta en memoria.
Con el fin de evitar que cualquier página pueda recuperar el estado que tenía el usuario en otra web distinta, las cookies llevan asociadas siempre un dominio y sólo pueden crearse, modificarse o borrarse si pertenecen al mismo dominio o al subdominio del nivel superior. Por ejemplo, si estamos visitando a.b.c.com el código podrá escribir cookies en a.b.c.com y b.c.com, pero no en c.com. Otra restricción de seguridad, es que nunca se pueden crear cookies pertenecientes a un TLD (por ejemplo el .com), a este tipo de cookies, se les llama supercookies. Como medida de seguridad adicional, podemos crear las cookies de forma que sólo se puedan leer desde una URL concreta.

Veamos ahora un ejemplo gráfico de lo que ocurre cuando se crean cookies en el cliente y en el servidor:

Cookies cómo funcionan

En el ejemplo anterior todas las cookies pertenecen al dominio www.humanlevel.com, pero ¿qué ocurre si incluimos en www.humanlevel.com un JavaScript que se enlaza desde otro dominio (por ejemplo googleads.g.doubleclick.net)?

Lo que ocurre es que cuando se ejecuta en el navegador, el JavaScript, puede crear, modificar y leer cookies de nuestro dominio, por lo que en el ejemplo anterior, el JavaScript externo tendría acceso a nuestras cookies ejemplo1 y ejemplo2 y podría reenviarlas a sus servidores mediante una petición AJAX cruzada. Por eso, como ya comenté en otra entrada cuando hablé de ataques XSS, para mejorar la seguridad de las cookies de sesión, se recomienda marcarlas siempre como Httponly, así evitamos que puedan ser leídas por un JavaScript externo. Además, si las marcamos como Secure y usamos HTTPS irán cifradas.

Sin embargo, cuando se genera el script en el servidor de googleads.g.doubleclick.net, no estamos en nuestro dominio, si no en googleads.g.doubleclick.net y, por lo tanto, sólo puede crear cookies para ese dominio, pero que igualmente llegan a nuestro navegador y se guardan. Esto es lo que se llaman cookies de terceras partes, ya que se introducen al visitar nuestra web pero no pertenecen a nuestro dominio. De esta forma, si luego visitamos otra página que use el mismo JavaScript, u otro JavaScript de otro dominio de la misma empresa que mande peticiones AJAX cruzadas a googleads.g.doubleclick.net, éste podrá recuperar la cookie de googleads.g.doubleclick.net desde el lado del servidor. Esta cookie tendrá un identificador que servirá para recuperar la información captada del usuario y así poder mantener el estado entre dominios distintos. Una de las aplicaciones más usadas de esta técnica, es mostrar anuncios de las páginas que hemos visitado.

Veamos otro ejemplo gráfico de como ocurre esto:

cookies2

En el momento de realizar la primera petición, el servidor puede leer la URL de donde viene la petición del parámetro HTTP_REFERER de la cabecera HTTP o, una vez se ejecute el JavaScript en el cliente, enviarse a sí mismo esta información. De esta forma, para cada web que visita el usuario, en el servidor de Adsense se va guardando el historial asociado al identificador de la cookie NID. Por eso, si la web que había visitado previamente tenía campañas de Adwords, aparecerán sus anuncios en la web que esté visitando en ese momento.

Por si todo esto no fuera ya de por sí, suficientemente complicado, también tenemos las llamadas cookies zombis, que se vuelven a crear después de borrarlas, debido a que algunos scripts las regeneran cada cierto tiempo.

Todo esto hace que la implementación de la ley anticookies sea bastante compleja de llevar a cabo y sea necesario desarrollar una solución específica para cada web.

Referencias adicionales

  •  | 
  • Modificado el
Ramón Saquete
Ramón Saquete
Desarrollador web y consultor SEO técnico en Human Level. Graduado en Ingeniería Informática e Ingeniería Técnica en Informática de Sistemas. También es Técnico Superior en Desarrollo de Aplicaciones Informáticas y posteriormente obtuvo la Certificación de Aptitud Pedagógica. Experto en WPO e indexabilidad.

¿Y tú qué opinas? Deja un comentario

Por si acaso, tu email no se mostrará ;)

es