As páginas da web são uma zona de batalha de segurança da informação enquanto lutamos contra hackers que tentam roubar segredos da empresa. As páginas da web modernas costumam aproveitar recursos de mais de uma origem (domínio). À medida que aumenta a pressão em torno das preocupações de segurança que afetam os novos recursos, os webmasters têm uma lista crescente de opções de fabricantes de navegadores, incluindo recursos de”origem cruzada”para ajudar a evitar vazamentos de informações.
Medidas de segurança
Você já deve estar familiarizado com rel="noopener" , uma maneira de garantir que links de hipertexto e elementos de formulário com ações de saída, como links que abrem outro site em uma nova guia do navegador, não permitem uma página externa acesso a uma página interna por meio do Propriedade Window.opener .
Imagine clicar em um link que abre uma nova guia. Quando você fecha a nova guia, a página original foi secretamente trocada para uma com iscas de phishing. Os fabricantes de navegadores desejam fornecer configurações de segurança sofisticadas para webmasters, para que possamos bloquear e “permitir” domínios que podem usar, por exemplo, a propriedade Window.opener para prevenir exatamente esses ataques.
Você deve ter visto referências ao Cross-Origin-Resource-Sharing ( CORS ) campo de cabeçalho de resposta http. Os valores CORS ( Access-Control-Allow-* ) limitarão o acesso a apenas um conjunto de domínios que você especificar como uma lista. Quando sua página inclui análises, anúncios e outros recursos de script de terceiros, aqueles que não estão especificamente em uma lista de permissões (quando você usa CORS) são bloqueados e disparam mensagens de erro no console do navegador para informá-lo.
Colapso do Espectro
Quando as coisas ficam muito quentes, é mais seguro desligar totalmente o recurso do navegador. Foi isso que aconteceu com SharedArrayBuffers quando os fabricantes de navegadores o usaram para resolver problemas no futuro. Após uma prova de conceito demonstrou uma vulnerabilidade de “canal lateral” 6 meses após sua estreia em 2017, SharedArrayBuffers foi afastado em 2018 até recentemente, em janeiro de 2021.
Resumindo, um ataque de condição de corrida permitiu o acesso indevido a um cache de memória privado em CPUs vulneráveis ( Spectre ), que por sua vez permite o acesso teórico por uma página de malware a outras páginas que um usuário pode ter aberto em outro contexto de navegador (sessão). As informações que vazam desse tipo de ataque podem constituir informações de identificação pessoal altamente confidenciais que podem expor uma pessoa a roubo de identidade e, potencialmente, permitir ataques direcionados contra organizações, incluindo sistemas governamentais.
Google Android Chrome 88 e desktop Chrome 91, mais Firefox 79+, todos implementam SharedArrayBuffers novamente depois de decidirem que uma nova configuração de política de segurança atenua o perigo de acesso de terceiros à memória privada. O acesso à memória compartilhada é bloqueado para todos os recursos não especificamente em uma lista de permissões seguindo o protocolo, conforme descrito nas novas diretivas de resposta http.
Falhas silenciosas
APIs como WebGLRenderingContext implementar o recurso, que estava falhando silenciosamente durante o período de blecaute provisório. Implementações que anteriormente passavam despercebidas, em que os desenvolvedores desconheciam e não tinham as novas configurações de segurança, de repente estão recebendo avisos no Google Search Console conforme os relatórios de falha começam a se acumular.
E-mails de erro GSC incompreensíveis atingindo novas alturas hoje: # SharedArrayBuffers #COOP #COEP pic.twitter.com/v02I6nh6iX
-Joost de Valk (@jdevalk) 15 de março de 2021
Implementando a nova política de segurança
Há muito tempo é uma prática recomendada estabelecer uma política de segurança com CORS como um perímetro em torno apenas dos recursos de terceiros que você pretende usar. Sem uma política de segurança em vigor, recursos de terceiros já causam estragos suficientes, muito menos potencialmente vazar seus segredos. Você deseja permitir a lista de recursos que falham usando uma política de segurança “ desconfiar por padrão ”. Apenas trabalhando intencionalmente a partir de falhas (scripts bloqueados) você gostaria de adicionar à sua lista de permissões para limitar o risco.
As configurações devem ser definidas usando os cabeçalhos de resposta http da página de ponto de entrada. Quando você gerencia seu próprio servidor da web, pode editar cabeçalhos de página usando as definições de configuração na estrutura ou pilha de tecnologia que alimenta seu site. Como alternativa, algumas Content Delivery Networks (CDNs) oferecem a capacidade de alterar cabeçalhos de resposta em tempo real. De qualquer forma, é uma questão de adicionar nomes e valores de campo, uma diretiva por linha.
Isolamento de origem cruzada
O ambiente de segurança onde você bloqueia o acesso, enquanto permite a nova implementação de SharedArrayBuffers, é chamado de isolamento de origem cruzada . Para configurar o Isolamento de origem cruzada , adicione dois novos cabeçalhos de página , COOP e COEP, conforme descrito abaixo, que funcionam em conjunto com um ou mais cabeçalhos de segurança, nomeadamente CORS e/ou CORP , que individualmente ou em combinação fornece seus domínios de origem cruzada na lista branca.
Cross-Origin-Embedder-Policy : require-corp
Cross-Origin-Opener-Policy : mesma origem
O Google usa o código aberto do Chrome API de relatórios para coletar ações que ocorrem contra essas políticas de segurança. Quando um número significativo se acumula, eles podem tentar encontrar uma maneira de notificá-lo, como parece ser o caso quando você é um usuário do Google Search Console.
Um campo de cabeçalho de página específico do Chrome Report-To pode ser usado para transmitir dados para seu próprio repositório, embora seja muito mais fácil simplesmente verificar o estado booleano do crossOriginIsolated propriedade experimental do WindowWorkerGlobalScope API durante o desenvolvimento. Dessa forma, você consegue lidar com esses problemas diretamente de seu fluxo de trabalho de desenvolvimento.
if (crossOriginIsolated) { //Post SharedArrayBuffer console.log ("CrossOriginIsolation: true")
} outro { //Faça outra coisa console.log ("CrossOriginIsolation: false")
}
Por que nos importamos
Como as falhas nas práticas recomendadas da política de segurança já acionam avisos no Lighthouse e mensagens de erro nos consoles do navegador e, neste caso, no serviço Search Console do Google, precisamos entender os detalhes para oferecer nosso conselho sobre o que fazer. Se estivermos envolvidos no desenvolvimento da web, queremos ter informações específicas preparadas para que possamos orientar ou conduzir a implementação de uma correção como parte de nosso trabalho.
Para obter mais informações como esta, confira o SMX SEO for Developers Workshop , com o objetivo de nos fornecer uma plataforma para discutir os problemas técnicos que enfrentamos e que podem ser exclusivos dos profissionais de otimização de mecanismos de pesquisa. Em um ambiente de workshop de código ao vivo, geralmente demonstramos o que os desenvolvedores da web experientes em SEO fazem ao enfrentar esses problemas e muito mais. A segurança da informação é importante, conforme evidenciado por SharedArrayBuffers , alterações na política de cookies , e muitos outros assuntos provavelmente estão no horizonte.
Sobre o autor
