Resumo: melhores práticas de segurança de scripts de terceiros
- Em todo o lado, com todos os privilégios: O JavaScript de terceiros está por todo o lado (mediana: 22 scripts por página) e é executado com os mesmos privilégios do seu próprio código.
- A violação do fornecedor é a sua: Se um fornecedor for comprometido, o mesmo acontece ao seu site: scripts maliciosos podem aceder a dados de utilizadores, campos de formulário, cookies e tokens de sessão.
- Quatro práticas a aplicar: As melhores práticas para a segurança de scripts de terceiros incluem: um inventário de scripts em tempo real + acesso com privilégio mínimo aos scripts + verificações de integridade com deteção de alterações e alertas + monitorização contínua em tempo de execução
- Onde encaixa uma ferramenta especializada: Algumas destas boas práticas podem ser implementadas com controlos do navegador como o CSP ou monitorização manual, mas a proteção real e a conformidade com frameworks como o RGPD e o PCI DSS dependem de uma ferramenta especializada de fornecedor, como o cside.
Sem tempo? Veja o bloqueio in-browser de Magecart e skimmers da cside. Cobre tudo o que se segue numa única implementação.
Melhores práticas para proteger scripts de terceiros em páginas web
De acordo com o Web Almanac 2024 do HTTP Archive, 92% das páginas web utilizam recursos de terceiros. Os ficheiros JavaScript são o tipo de recurso de terceiros mais comum, representando cerca de 30% dos pedidos de terceiros. Em 2024, a página móvel mediana fez 22 pedidos de JavaScript por página. No percentil 90, esse número subiu para 68. No desktop, os números situam-se na mesma gama, com 23 e 70, respetivamente.
Uma vez permitidos, os scripts correm livremente. Quando um fornecedor é comprometido ou uma CDN é adulterada, código malicioso pode infiltrar-se no navegador dos utilizadores. Neste artigo, analisamos boas práticas concretas de segurança de scripts de terceiros, sem sacrificar velocidade ou funcionalidade, para que possa proteger o JavaScript de terceiros de que o seu site depende.
1. Inventário completo e visibilidade dos scripts
Um "inventário" em tempo real de todos os scripts servidos aos utilizadores no navegador é um bom ponto de partida. O inventário deve rastrear de onde o código é carregado: um fornecedor/biblioteca de terceiros que escolheu, ou algum quarto partido obscuro?
sem inventário = sem visibilidade = sem controlo
As páginas de pagamento são especialmente de alto risco. Num mundo perfeito, não existiriam scripts de terceiros em páginas de pagamento. Risco zero. Mas isso não vai acontecer. Os processadores de pagamento e outras ferramentas de checkout exigem JavaScript para o fluxo de pagamento.
Uma plataforma de proteção client-side como o cside elimina o trabalho manual, gerando e mantendo automaticamente um inventário de scripts em tempo real.
2. Acesso aos scripts com privilégio mínimo
Para cada script, verifique que dados ele toca e pergunte-se: porquê? Preste muita atenção a scripts que acedem a dados sensíveis, como campos de formulário, cookies ou tokens de sessão. Nem todos os scripts precisam de privilégios totais, mas sem controlos em vigor os scripts têm um caminho direto para obter informação sensível.
Porque é que um script de análise precisaria de aceder a dados de pagamento? Os pixels de marketing não têm motivo nenhum para ler logins e palavras-passe, certo?
CSP para restringir que scripts são carregados
Por predefinição, os navegadores executam qualquer script, incluindo scripts encadeados. Restringir o acesso aos dados é fundamental para a sua defesa. Uma Content Security Policy (CSP) define de onde o código pode ser carregado: por exemplo, apenas os seus próprios servidores e fontes de terceiros na lista de permissões. Estas regras são definidas nos cabeçalhos HTTP ou no HTML, e o navegador aplica-as.
O CSP verifica apenas de onde o código é carregado, mas não o que faz depois de estar em execução. O código é dinâmico e é atualizado. Se código malicioso for carregado a partir de uma fonte de confiança, o seu CSP não o vai bloquear.
O CSP é um ponto de partida, mas está longe de ser uma defesa completa. As CSPs baseiam-se inteiramente no domínio de origem de onde um script é carregado e não analisam os comportamentos dos scripts.
Com o cside, pode configurar políticas que restringem o acesso dos scripts por comportamento. Ou seja, é possível permitir que scripts específicos leiam cookies ou campos de formulário, enquanto todos os outros scripts (incluindo os aprovados) ficam bloqueados de executar ações de risco no navegador.
3. Verificar a integridade, detetar alterações e configurar alertas
O seu mecanismo de rastreio também deve vigiar alterações e atualizações aos scripts. Um script pode estar saudável e seguro num dia e ter a sua integridade comprometida com uma atualização.
Um controlo nativo do navegador para isto é o Subresource Integrity (SRI). O SRI adiciona um hash criptográfico a scripts ou tags link. Funciona como uma garantia da integridade do código. Quando o navegador carrega um script, verifica o hash. Se um único byte for diferente, o navegador não executa o código. O SRI funciona bem para proteger recursos estáticos de terceiros e deteta modificações ao nível da CDN. Mas o SRI falha com scripts dinâmicos, dos quais depende a maioria dos sites modernos.
Uma solução de fornecedor (como o cside) pode ser usada para monitorizar a integridade dos scripts através de várias camadas de um motor de deteção. As equipas de segurança são alertadas automaticamente quando existe uma anomalia comportamental ou um comprometimento conhecido de um fornecedor na cadeia de abastecimento.
4. Utilize monitorização em tempo de execução que analisa o comportamento dos scripts
Os "scanners remotos" são fáceis de implementar, mas têm visibilidade limitada. Uma investigação da ISACA conclui que estas ferramentas de teste de segurança falham na deteção de ameaças em que o código é carregado condicionalmente para evitar tais verificações. As soluções do tipo "scanner" também estão limitadas à deteção, com pouca capacidade para bloquear código malicioso.
Rever código de terceiros antes da implementação em produção também tem limitações. Muitos scripts são aprovados uma vez, raramente revistos, mas alteram-se com frequência. Um script pode passar na revisão antes de ser publicado e, meses depois, ter código malicioso inserido no seu interior.
A monitorização em tempo de execução deteta scripts comprometidos provenientes de fontes de confiança. Quando um script começa subitamente a ler campos de formulário ou a fazer pedidos de rede, verifique o seu inventário e bloqueie-o. A monitorização em tempo de execução consiste em observar os scripts em ação. Mesmo aspetos como a manipulação do DOM podem ser rastreados com monitorização em tempo de execução.
Fazer isto através de ferramentas construídas internamente rapidamente se torna inviável. Acaba por criar o seu próprio antivírus e investir recursos consideráveis num projeto que não faz parte do seu negócio principal. Existem muitas soluções prontas a usar, como o cside, que executam automaticamente a monitorização em tempo de execução nas suas páginas e organizam os dados em dashboards e alertas claros.
Para equipas que gerem scripts em muitas propriedades, a monitorização de scripts de terceiros em 100 ou mais domínios aborda padrões de deteção multi-domínio na prática.
5. Alinhamento com a conformidade
A conformidade tem fama de implicar burocracia demorada. Os controlos client-side são exigidos por uma lista crescente de frameworks, incluindo o RGPD, o PCI DSS e o CCPA/CPRA.
As organizações de saúde também enfrentam obrigações de conformidade HIPAA no rastreio de websites quando pixels de terceiros são executados em páginas voltadas para pacientes, e leis estaduais de privacidade dos EUA, como o Texas Data Privacy and Security Act, exigem transparência dos dados ao nível dos scripts para empresas que servem residentes do Texas.
Certifique-se de que as suas atividades de processamento de scripts de terceiros estão alinhadas com as expectativas destas frameworks: transparência, limitação de finalidade e proteção de dados. Isto significa que precisa de compreender exatamente como os scripts de terceiros se comportam, para os poder divulgar com precisão nos seus avisos de privacidade. Por predefinição, os scripts só devem recolher os dados necessários (remetendo para o acesso com privilégio mínimo) e as salvaguardas de segurança devem proteger os utilizadores contra a exfiltração de dados client-side.
Um bom ponto de partida como boa prática é conhecer os DPA (acordos de processamento de dados) de cada fornecedor terceiro que adiciona ao seu site. Estes documentos descrevem como pretendem processar os dados recolhidos dos seus utilizadores. Para garantir que a atividade real corresponde a essas expectativas, implemente uma ferramenta de monitorização de scripts de terceiros como o cside.
O que é o risco de quarto partido?
O risco de quarto partido é a exposição de segurança e de conformidade criada por scripts, pixels e serviços carregados pelos seus fornecedores terceiros, ou seja, as dependências das suas dependências. Quando incorpora uma plataforma de gestão de tags, esta pode carregar scripts adicionais de fornecedores de análise, redes publicitárias e ferramentas de otimização. Esses scripts de quarto partido recebem o mesmo acesso ao seu DOM, formulários e dados de utilizador que o código incluído diretamente, mas ficam totalmente fora da maioria dos programas de gestão de risco de fornecedores e dos inventários de CSP.
O problema prático: audita o seu código de primeira parte. Revê os fornecedores terceiros antes de os adicionar. Mas quando o seu gestor de tags carrega um pixel de marketing, esse pixel carrega um script de retargeting, e esse script carrega um SDK de otimização, ficam três camadas de código a executar nos navegadores dos seus utilizadores que nunca aprovou e cuja existência pode nem conhecer.
Porque é que o CSP não o deteta: uma Content Security Policy define uma lista de permissões de domínios, não de código. Se o seu gestor de tags estiver na lista de permissões, tudo o que esse gestor de tags carregar é permitido pelo seu CSP, incluindo scripts de quarto partido que o fornecedor adicionou à sua própria plataforma sem o notificar. Detetar o risco de quarto partido exige um inventário em tempo de execução: observar o que cada script carrega realmente em sessões reais, e não apenas verificar domínios de origem numa lista estática.
O inventário de scripts do cside capta todos os scripts na cadeia de execução, de primeira, terceira e quarta parte, em cada sessão real. Qualquer script que não conste do inventário aprovado dispara um alerta antes de poder aceder a campos de formulário ou exfiltrar dados.
Por que os sites dependem de JavaScript de terceiros
É uma boa prática de negócio os construtores não fabricarem os seus próprios tijolos, mas confiarem em especialistas para os materiais e a engenharia. O mesmo se aplica aos programadores web: utilizam ferramentas de terceiros para análise, pagamentos online, widgets e outras funcionalidades que tornam os sites dinâmicos e interativos.
Não há necessidade de reinventar soluções que já existem. As ferramentas especializadas fazem o trabalho, permitindo às equipas web concentrarem-se no negócio principal em vez da interface do utilizador, testes A/B, fluxos de pagamento online, análise, rastreio de localização, entre outros.
Por que os scripts de terceiros são um grande risco para a segurança client-side
O problema de privilégios dos scripts de terceiros
Eis o problema: no navegador, todo o JavaScript é tratado da mesma forma.
O DOM não distingue entre o seu código e o código de um fornecedor. Os scripts de terceiros obtêm o mesmo acesso a dados de utilizadores e campos de formulário que o seu próprio código de primeira parte. Podem ler campos de formulário, aceder a cookies, modificar o conteúdo da página e fazer pedidos de rede.
É precisamente essa vulnerabilidade que os agentes maliciosos procuram.
O problema da cadeia de abastecimento dos scripts de terceiros
Isto significa que, se a infraestrutura de um fornecedor for comprometida, scripts maliciosos podem ser injetados diretamente no seu site.
Na mediana, 21% dos scripts em páginas móveis são injetados dinamicamente. No percentil 90, esse número chega mesmo aos 70%. No desktop, os números são comparáveis.
Os scripts injetados podem criar um ponto cego de segurança, porque estão fora do perímetro das ferramentas tradicionais de segurança web. Isto também implica que scripts de terceiros injetados dinamicamente podem, por sua vez, injetar scripts adicionais que nunca aprovou.
uma violação num dos seus fornecedores = uma violação na sua aplicação
Pior ainda: um script comprometido pode propagar-se em cascata por todos os sites que o utilizam. Uma única fragilidade num script amplamente usado pode transformar-se num ataque de larga escala à cadeia de abastecimento.
Leitura relacionada: o cluster de segurança de scripts de terceiros
Use este artigo como ponto de partida e depois aprofunde as partes específicas da segurança de scripts de terceiros que mais importam à sua equipa:
- Um framework de gestão de risco de scripts de terceiros transforma estas melhores práticas num processo de governação repetível.
- O que é a injeção de JavaScript? explica a técnica de ataque que permite a um script comprometido executar código não aprovado no navegador.
- Ataques Magecart explicados: web skimming aborda a forma mais comum de os scripts de terceiros serem usados como arma contra páginas de checkout e de pagamento.
- Segurança client-side da cside mostra como um único fragmento de JavaScript próprio entrega o inventário, os controlos de menor privilégio, as verificações de integridade e a monitorização em tempo de execução numa única implementação.
- Conformidade com o PCI DSS com a cside liga a segurança de scripts de terceiros aos requisitos de evidência 6.4.3 e 11.6.1 do PCI DSS para páginas de pagamento.
