Este artigo faz parte de uma série sobre as mudanças de atributos de cookies SameSite:
SameSite
Schemeful Same-Site modifica a definição de um site (da Web) de apenas o domínio registrável para o esquema + o domínio registrável. Mais detalhes e exemplos podem ser encontrados em Understanding "same-site" and "same-origin".
Termo-chave: significa que a versão HTTP não segura de um site, como http://website.example, e a versão HTTPS segura desse mesmo site, https://website.example, agora são consideradas, uma em relação à outra, dentro de um contexto entre sites.
A boa notícia é que, se o upgrade do site para HTTPS já estiver concluído, você não precisa se preocupar com mais nada. Nada muda para você, nesse caso.
Se o upgrade do site ainda não estiver concluído, essa deve ser a prioridade. No entanto, se houver casos nos quais os visitantes do site alternem o HTTP e o HTTPS, alguns desses cenários comuns e o comportamento do cookie SameSite associado são descritos a seguir.
Aviso: no longo prazo, o plano é desativar gradual e totalmente o suporte a cookies de terceiros, substituindo-o por alternativas que preservem a privacidade. A definição de SameSite=None; Secure em um cookie para permitir que ele seja enviado entre esquemas só deve ser considerada como uma solução temporária na migração para o HTTPS total.
SameSite=None; Secure
Você pode ativar essas mudanças para teste no Chrome e no Firefox.
chrome://flags/#schemeful-same-site
network.cookie.sameSite.schemeful
true
about:config
Um dos motivos principais da mudança para SameSite=Lax como padrão para cookies foi a proteção contra ataques de falsificação de solicitação entre sites (CSRF, na sigla em inglês). No entanto, o tráfego HTTP não seguro ainda representa uma oportunidade para que invasores de redes adulterem cookies que são, então, utilizados na versão HTTPS segura do site. A criação desse limite adicional entre sites entre os esquemas oferece uma defesa melhor contra esses ataques.
SameSite=Lax
Termo-chave: nos exemplos abaixo, onde todos os URLs têm o mesmo domínio registrável, como site.example, mas esquemas diferentes, como http://site.example versus https://site.example, eles são referenciados como entre esquemas um em relação ao outro.
A navegação pelas versões entre esquemas de um site (por exemplo, um link de http://site.example para https://site.example) anteriormente permitiria o envio de cookies SameSite=Strict. Isso agora é tratado como uma navegação entre sites, o que significa que os cookies SameSite=Strict são bloqueados.
SameSite=Strict
SameSite=None;Secure
Aviso: todos os principais navegadores bloqueiam conteúdo misto ativo, como scripts ou iframes. Além disso, alguns navegadores, incluindo Chrome e Firefox, estão trabalhando no upgrade ou bloqueio de conteúdo misto passivo.
Quaisquer mudanças feitas aqui só devem ser consideradas correções temporárias enquanto você trabalha no upgrade para o HTTPS total.
Exemplos de sub-recursos incluem imagens, iframes e solicitações de rede feitas com XHR ou Fetch.
O carregamento de um sub-recurso entre esquemas em uma página anteriormente permitira o envio ou a definição de cookies SameSite=Strict ou SameSite=Lax. Agora, isso é tratado da mesma forma que qualquer outro sub-recurso entre sites ou de terceiros, o que significa que todos os cookies SameSite=Strict ou SameSite=Lax são bloqueados.
Além disso, mesmo que o navegador permita o carregamento de recursos de esquemas não seguros em uma página segura, todos os cookies são bloqueados nessas solicitações, porque os cookies entre sites ou de terceiros exigem Secure.
Secure
A postagem entre versões entre esquemas de um site anteriormente permitiria que cookies definidos com SameSite=Lax ou SameSite=Strict fossem enviados. Isso agora é tratado como um POST entre sites — apenas os cookies SameSite=None podem ser enviados. Esse cenário pode ser encontrado em sites que apresentam a versão não segura por padrão, mas que fazem upgrade dos usuários para a versão segura no envio do formulário de login ou da finalização da compra.
SameSite=None
Assim como no caso dos sub-recursos, se a solicitação for de um contexto seguro, como HTTPS, para um não seguro, como HTTP, todos os cookies são bloqueados nessas solicitações, uma vez que os cookies entre sites ou de terceiros exigem Secure.
Aviso: a melhor solução nesse caso é garantir que a página e o destino do formulário estejam em uma conexão segura, como HTTPS. Isso é especialmente importante se o usuário estiver inserindo informações confidenciais no formulário.
As mensagens e ferramentas para desenvolvedores estão disponíveis no Chrome e no Firefox.
No Chrome 86, a guia Issue em DevTools inclui os problemas relacionados ao Schemeful Same-Site. Os seguintes problemas podem ser destacados para um site.
Problemas de navegação:
Problemas de carregamento de sub-recursos:
Mais detalhes podem ser encontrados em Testing and Debugging Tips for Schemeful Same-Site.
No Firefox 79, com network.cookie.sameSite.schemeful definido como true via about:config, o console exibe a mensagem para problemas com o Schemeful Same-Site. Você pode ver o seguinte em seu site:
cookie_name
http://site.example/
É possível que alguns dos links e sub-recursos ainda apontem para URLs não seguros.
Uma forma de corrigir o problema é usar o HSTS HTTP Strict-Transport-Security e a diretiva includeSubDomain. Com o HSTS + includeSubDomain, mesmo que uma das páginas acidentalmente inclua um link não seguro, o navegador usa automaticamente a versão segura.
includeSubDomain
Embora seja altamente recomendável fazer upgrade do site totalmente para HTTPS a fim de proteger os usuários, se você não puder fazer isso, sugerimos falar com seu provedor de hospedagem para ver se ele oferece essa opção. Se a hospedagem for própria, a Let's Encrypt oferece várias ferramentas para instalar e configurar um certificado. Outra opção é tentar colocar o site por trás de um CDN ou outro proxy capaz de fornecer a conexão HTTPS.
Se isso também não for possível, tente afrouxar a proteção do SameSite sobre os cookies afetados.
Lax
Strict
None
Os cookies sem um atributo SameSite são tratados como se tivessem especificado SameSite=Lax, e o mesmo comportamento entre esquemas se aplica a eles. Observe que a exceção temporária para métodos não seguros também se aplica. Consulte sobre a mitigação de Lax + POST nas Perguntas frequentes do SameSite no Chromium para obter mais informações.
As conexões WebSocket ainda serão consideradas do mesmo site se tiverem a mesma segurança da página.
Do mesmo site:
wss://
https://
ws://
http://
Entre sites:
Foto de Julissa Capdevilla em Unsplash
Postar um comentário
Nenhum comentário :
Postar um comentário