Cookies - SameSite Attribute

Photo by Mohammad Rahmani on Unsplash

A partir da versão 84, o Chrome define o atributo SameSite dos Cookies como Lax por padrão. Serviços que usam Third-party cookies podem ser afetados se não configurarem o SameSite corretamente.

Visão Geral

Cookies são mecanismos usados em serviços web para armazenar estado, comumente usados para manter sessões de login, carrinhos de compras, rastreamento de anúncios, etc. No entanto, o uso generalizado de Cookies também traz preocupações de privacidade e segurança, e o SameSite foi introduzido para resolver esses problemas.

First-Party and Third-Party

Com base na origem do Cookie (Set-Cookie), cada Cookie tem um Domínio específico. Ao olhar para a URL atual no navegador do usuário, se o Domínio do Cookie corresponder à URL atual, é First-Party; caso contrário, é Third-Party.

Third-party

Por exemplo, ao navegar no site a.com, uma solicitação (request) é enviada para third-party.com e recebe um Cookie de third-party.com. Como o navegador inclui automaticamente Cookies com o mesmo Domínio nas solicitações, se você navegar mais tarde em outro site como b.com e ele também enviar uma solicitação para third-party.com, o servidor receberá o Cookie. Para esses dois sites, o Cookie third-party.com é Third-party.

First-party

Se você navegar em um site que corresponda ao Domínio third-party.com, o Cookie também será enviado. Neste caso, este Cookie é chamado de First-party.

Same-Origin and Same-Site

O exemplo anterior mencionou o uso do Domínio para determinar o tipo de Cookie, mas uma maneira melhor de dizer isso é determinando se o Site é o mesmo. Isso se relaciona com o Same-origin frequentemente visto?

Cookies SameSite

Origin

Origin é composto por Scheme, Host e Port. O método de determinação é muito simples: se o Scheme, Host e Port de duas URLs forem todos idênticos, são Same-origin; caso contrário, são Cross-origin.

Site

A determinação de Same-Site envolve Effective top-level domains (eTLDs). Todos os eTLDs são definidos na Public Suffix List, e um Site é composto por um eTLD mais um prefixo.

Por exemplo: github.io existe na Public Suffix List. Adicionar um prefixo (por exemplo, a.github.io) torna-o um Site. Portanto, a.github.io e b.github.io são dois Sites diferentes (Cross-site).

example.com não existe na Public Suffix List, mas .com sim, então example.com é um Site, e a.example.com e b.example.com são o mesmo Site (Same-site).

Observe que o Site não inclui a Porta, portanto, mesmo que as Portas sejam diferentes, ainda podem ser Same-site.

Why SameSite?

O mecanismo onde “qualquer Solicitação carrega cookies desse Domínio” também trouxe problemas de segurança e outros, sendo o mais importante o Cross-site request forgery (CSRF).

CSRF

Suponha que um usuário tenha feito login em example.com e obtido um Cookie. Quando o usuário navega em um site malicioso evil.com, o JavaScript nesse site pode enviar uma Solicitação POST para example.com/pay?amount=1000. O navegador incluirá automaticamente o Cookie example.com, e o usuário paga 1000 dólares sem saber. O Servidor não consegue determinar de onde veio essa Solicitação (Request).

Limitações

Cookies em si não podem ser configurados para serem enviados apenas em um ambiente First-party, portanto, as Solicitações carregam Cookies em qualquer ambiente. O Servidor não consegue identificar a fonte da Solicitação e só pode responder como de costume, fazendo com que o Cliente desperdice largura de banda enviando Cookies inúteis.

Solução

Com o atributo SameSite, podemos configurar individualmente as condições para enviar Cookies em diferentes ambientes.

SameSite

O atributo SameSite tem três valores. Configurá-lo como Strict ou Lax pode restringir os Cookies para serem enviados apenas em Solicitações Same-Site. Se deixado em branco, o comportamento depende do navegador; para o Chrome, o padrão é Lax.

Strict

Cookies são enviados apenas em um ambiente First-party. No entanto, há um problema: suponha que um usuário veja um link de postagem do Facebook em example.com (digamos fb.com). Mesmo que o usuário tenha feito login em fb.com e tenha um Cookie, clicar no link não enviará o Cookie porque os dois sites são Cross-site, então eles verão apenas a página de login.

Portanto, Strict é adequado para ações sensíveis, como excluir postagens, fazer pagamentos, etc.

Lax

Para resolver as limitações excessivamente rígidas do Strict, o Lax permite o envio de Cookies mesmo em situações Cross-site nos seguintes casos:

Digitar uma URL na barra de endereços
Clicar em um link <a href="...">
Enviar um formulário <form method="GET">
Prerendering <link rel="prerender" href="...">

Esses casos têm dois pontos em comum: todos são solicitações GET e todos acionam a Navegação de Nível Superior (Top-level Navigation). Isso evita o problema do Strict exigir o login novamente todas as vezes e também impede o envio de Cookies sem saber ao navegar em outros sites.

Lax + POST

No entanto, para evitar quebrar alguns fluxos de login existentes, o Chrome atualmente relaxa ligeiramente a restrição para SameSite=Lax, dando aos desenvolvedores mais tempo para se adaptarem.

Dentro de dois minutos após a definição do Cookie, independentemente do Método de Solicitação (Request Method), desde que acione uma navegação de página de nível superior, o Cookie será enviado. Isso significa que se o navegador mudar de página, por exemplo, enviando um formulário <form method="POST">.

Para detalhes, consulte o tópico sobre Lax + POST.

None

Para enviar um Third-party cookie, você deve configurar SameSite=None; Secure. Sim, a partir de agora, se você quiser enviar um Third-party cookie em um ambiente de teste, por favor, prepare https://localhost.

Além disso, enviar Cross-Origin Requests via XHR/Fetch requer configurar withCredentials: true para enviar o Cookie e tornar o Set-Cookie no cabeçalho de Resposta efetivo. O Servidor também deve configurar Access-Control-Allow-Credentials: true no cabeçalho de Resposta para que o JavaScript acesse o conteúdo da Resposta.

Navegadores Não Suportados

Nem todos os navegadores suportam as regras mais recentes do SameSite ainda, portanto, algumas soluções alternativas (Workarounds) temporárias podem ser adicionadas no Servidor para suportar vários navegadores:

Definir Ambos os Cookies

Este método pode resolver problemas para quase todos os navegadores, mas a desvantagem é que haverá duas cópias do Cookie:

Set-cookie: name=value; SameSite=None; Secure
Set-cookie: name-legacy=value; Secure

Código do lado do servidor:

if (req.cookies['name']) {
  // Use o novo se disponível
  cookieVal = req.cookies['name'];
} else if (req.cookies['name-legacy']) {
  // Caso contrário, use o antigo
  cookieVal = req.cookies['name-legacy'];
}

User Agent

Determine o navegador usando o User agent da Solicitação para decidir o conteúdo de Set-Cookie. Este método requer apenas a modificação do código que define o Cookie, sem alterar a parte de Análise (Parsing). No entanto, este método de julgamento envolve mais variáveis e torna mais fácil definir o Cookie errado.

Revisão

Cookies sem o atributo SameSite definido terão como padrão SameSite=Lax e não poderão ser enviados em um ambiente Cross-site.
Para enviar Cookies em Cross-site, você precisa configurar SameSite=None; Secure.
Você pode usar o SameSite sandbox para testar se o seu navegador atual está em conformidade com as regras mais recentes do SameSite.