Auditoria de scripts de terceiros e SRI
Cada script de terceiros que a sua página carrega é executado com todos os privilégios da página: pode ler o DOM, observar o que é escrito nos formulários e agir dentro das sessões dos seus visitantes. Esta auditoria obtém o HTML estático de uma página, lista cada script externo a que ela faz referência, marca quais são de terceiros, quais trazem um hash de Subresource Integrity (SRI) e quais estão fixados numa versão exata — e, para os scripts de terceiros sem integridade, calcula o hash sha384 para que possa colá-lo diretamente na etiqueta.
Última atualização:
Preocupa-o que um script de um fornecedor no seu site mude ou caia? Vigie grátis com o myeventwatch — alertas de expiração e indisponibilidade, sem cartão.
O que esta auditoria verifica — e o que não consegue ver
O verificador obtém a página uma vez e analisa o HTML que lhe é servido: apenas o HTML estático. Cada <script src> dessa marcação é listado com o seu anfitrião, classificado como próprio quando o anfitrião coincide com o domínio registável da sua página e como de terceiros quando não, e verificado quanto aos dois atributos que decidem se o navegador o pode proteger: integrity, o hash SRI que o navegador verifica antes de executar o ficheiro, e crossorigin, de que uma verificação SRI entre origens precisa para funcionar. A versão no URL também é avaliada: um script endereçado como [email protected] ou /v2.4/ está fixado, enquanto um endereço latest ou sem versão é um alvo móvel cujo conteúdo pode mudar a qualquer momento sem que ninguém toque no seu site.
Tenha clara a fronteira, porque ela importa: a v1 analisa apenas o HTML estático da página — os scripts injetados em tempo de execução por JavaScript não estão cobertos. Os gestores de etiquetas, as ferramentas de consentimento e os widgets de chat criam habitualmente elementos script a partir de código depois de a página carregar, e uma análise estática nunca os vê. Trate esta auditoria como o inventário daquilo a que os seus modelos e o seu CMS fazem referência diretamente — normalmente a maior e mais reparável parte do problema — e audite os contentores do gestor de etiquetas separadamente, na pré-visualização e no histórico de alterações do próprio gestor. Os scripts em linha (blocos sem src) são contados como um facto no resultado, porque não podem trazer SRI de todo; o guia complementar explica o que fazer com eles.
A coluna do hash: calculado, nunca adivinhado
Para os scripts de terceiros sem o atributo integrity, o verificador obtém o próprio script — pelo mesmo caminho de obtenção protegido contra SSRF que todos os verificadores deste site usam, com um limite dos primeiros 15 scripts desse tipo e 512 KB cada — e calcula o seu hash SHA-384. Quando a obtenção tem sucesso, a célula SRI mostra o fragmento completo, integrity="sha384-…", pronto a colar na sua etiqueta junto a crossorigin="anonymous". Um hash só é mostrado quando o script foi realmente obtido. Se a obtenção falhou, o ficheiro era demasiado grande ou o script ficou além do limite de 15, a célula mostra essa nota — nunca um marcador nem um valor adivinhado — e a solução é gerar o hash na sua própria cadeia de construção, onde o ficheiro exato está à mão.
Verificações relacionadas: a verificação de cabeçalhos de segurança classifica os cabeçalhos de resposta — incluindo a Content-Security-Policy, a parceira natural do SRI —, o classificador SSL cobre o transporte por onde esses scripts chegam, e o artigo complementar os scripts de terceiros são um risco de cadeia de fornecimento percorre um incidente real, o que o SRI detém e o que não detém, e uma rotina de auditoria repetível.
Como devem ler-se os vereditos: um script de terceiros com integridade e versão fixada é o caso saudável — o navegador recusará um ficheiro trocado ou editado. Um script de terceiros sem integridade não é automaticamente malicioso; está desprotegido, o que significa que o seu conteúdo é aquilo que o seu anfitrião servir hoje, e o seu único aviso de uma alteração seria o próprio dano. Os endereços sem fixação merecem a mesma suspeita que os hashes em falta, porque um hash SRI sobre um URL latest se parte assim que o fornecedor publica uma atualização — é por isso que os dois achados são relatados lado a lado, e por isso a correção duradoura é sempre o par: fixe a versão exata e depois calcule o hash desse ficheiro exato.
Os factos que esta página mostra
| De terceiros | Um script cujo domínio registável difere do da página: código servido por outra pessoa, executado com os privilégios da sua página. |
| Integridade (SRI) | Se a etiqueta traz um atributo integrity: um hash criptográfico que o navegador verifica antes de executar o ficheiro, recusando-o perante qualquer diferença. |
| Crossorigin | Se a etiqueta traz o atributo crossorigin de que uma verificação SRI entre origens precisa; sem ele, os navegadores não podem aplicar SRI ao carregamento. |
| Fixado | Se o URL nomeia uma versão exata ([email protected], /v2.4/) em vez de um endereço latest flutuante ou sem versão cujo conteúdo pode mudar em silêncio. |
| SRI calculado | Para os scripts de terceiros sem integridade, o hash sha384 que o verificador calculou ao obter o ficheiro de verdade — mostrado apenas após uma obtenção com sucesso, para os primeiros 15 scripts desse tipo. |
Perguntas frequentes
Esta auditoria vê todos os scripts que a minha página executa?
Não — e a página diz isso claramente: a v1 analisa apenas o HTML estático da página, por isso os scripts injetados em tempo de execução por JavaScript não estão cobertos. Os gestores de etiquetas, as ferramentas de testes A/B, os banners de consentimento e os widgets de chat costumam injetar scripts após o carregamento; audite-os no gestor de etiquetas ou com o painel de rede de um navegador. O que esta auditoria cobre por completo é cada script a que o seu HTML servido faz referência diretamente, que é onde vivem as bibliotecas, os widgets de CDN e os códigos de monitorização.
De onde vem o hash na coluna SRI?
O verificador obtém o próprio ficheiro do script e calcula o seu hash SHA-384, para os scripts de terceiros sem atributo integrity: os primeiros 15, até 512 KB cada. Um hash só é mostrado quando o script foi realmente obtido: se a obtenção falhou, o ficheiro era demasiado grande ou o limite foi atingido, a célula mostra essa nota em vez de um hash. Cole o fragmento na sua etiqueta script juntamente com crossorigin="anonymous" e volte a executar a auditoria após qualquer mudança de versão: uma versão nova significa um hash novo.
O script do meu gestor de etiquetas não pode ter um hash fixo. E então?
Correto: um contentor de gestor de etiquetas foi concebido para mudar, por isso o SRI não o pode fixar, e o mesmo vale para qualquer script cujo propósito inteiro é carregar código mutável. Para esses, os controlos são outros: restrinja quem pode publicar no contentor, reveja o seu histórico de alterações como alterações de código, carregue-o apenas nas páginas que dele precisam e use uma Content-Security-Policy para limitar o que os scripts injetados podem fazer e para onde podem enviar dados. O SRI protege as bibliotecas fixas; a governação protege as dinâmicas.
A falta de um atributo integrity é uma emergência?
É uma exposição permanente, não um incidente. É quase certo que o script é o ficheiro que o fornecedor pretende servir hoje; o problema é que nada deteria nem assinalaria um ficheiro diferente amanhã, após uma intrusão no fornecedor, uma conta sequestrada ou um domínio expirado. Ordem de correção: primeiro os scripts em páginas com inícios de sessão, pagamentos ou dados pessoais; depois, bibliotecas fixadas e com hash em todo o lado; por fim, a cauda longa. Cada correção é uma mudança de uma linha na etiqueta, uma vez fixada a versão.
Porque é que a coluna de fixação chama a um script «latest» ou «sem versão»?
O veredito de fixação é uma leitura heurística do URL: um segmento com aspeto de versão, como @1.2.3 ou /v2.4/, conta como fixado; um segmento latest explícito conta como flutuante; e um URL sem versão em parte alguma conta como sem versão. É rotulado como heurística porque só o fornecedor conhece o seu esquema de versões — mas o ponto de segurança não depende do rótulo: se os bytes nesse URL podem mudar sem que o URL mude, um hash SRI não pode sobreviver, por isso primeiro fixe e depois calcule o hash.