Resumo
- JavaScript de terceiros está em todo lugar (mediana: 22 scripts por página) e é executado com os mesmos privilégios do seu próprio código.
- Se um fornecedor for comprometido, seu site também será: scripts maliciosos podem acessar dados de usuários, campos de formulário, cookies e tokens de sessão.
- As melhores práticas para segurança de scripts de terceiros incluem: inventário de scripts em tempo real + acesso com privilégio mínimo + verificações de integridade com detecção de alterações e alertas + monitoramento contínuo em tempo de execução.
- Algumas dessas práticas podem ser implementadas com controles do navegador, como CSP, ou monitoramento manual, mas a proteção real e a conformidade com frameworks como GDPR e PCI DSS dependem de uma ferramenta especializada como o cside.
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. Arquivos JavaScript são o tipo de recurso de terceiros mais comum, representando cerca de 30% das requisições de terceiros. Em 2024, a mediana de páginas mobile realizou 22 requisições JavaScript por página. No percentil 90, esse número subiu para 68. No desktop, os números ficam na mesma faixa: 23 e 70, respectivamente.
Uma vez permitidos, os scripts rodam livremente. Quando um fornecedor é comprometido ou uma CDN é adulterada, código malicioso pode se infiltrar no navegador dos usuários. Neste post, analisamos práticas recomendadas para a segurança de JavaScript de terceiros sem abrir mão de velocidade ou funcionalidade.
1. Inventário Completo e Visibilidade dos Scripts
Um "inventário" atualizado de cada script servido aos usuários no navegador é um bom ponto de partida. O inventário deve rastrear de onde o código é carregado: um fornecedor ou biblioteca de terceiros que você escolheu, ou algum quarto partido obscuro?
sem inventário = sem visibilidade = sem controle
Páginas de pagamento são especialmente de alto risco. Em um mundo ideal, não haveria scripts de terceiros em páginas de pagamento. Risco zero. Mas isso não é realidade. 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 ao gerar e manter automaticamente um inventário de scripts em tempo real para você.
2. Acesso com Privilégio Mínimo para Scripts
Para cada script, verifique quais dados ele acessa e pergunte-se: por quê? Fique atento a scripts que acessam dados sensíveis, como campos de formulário, cookies ou tokens de sessão. Nem todo script precisa de privilégios totais, mas sem controles em vigor os scripts têm um caminho direto para capturar informações sensíveis.
Por que um script de analytics precisaria acessar dados de pagamento? Pixels de marketing não têm nenhum motivo para ler logins e senhas, certo?
CSP para restringir quais scripts são carregados
Por padrão, os navegadores executam qualquer script, incluindo scripts encadeados. Restringir o acesso a dados é fundamental para sua defesa. Uma Content Security Policy (CSP) define de onde o código pode ser carregado: por exemplo, apenas seus próprios servidores e fontes de terceiros na lista de permissões. Você define essas regras nos seus cabeçalhos HTTP ou HTML, e o navegador as aplica.
O CSP verifica apenas de onde o código é carregado, mas não o que ele faz depois que está em execução. O código é dinâmico e é atualizado. Se um código malicioso for carregado a partir de uma fonte confiável, seu CSP não o bloqueará.
O CSP é um ponto de partida, mas está longe de ser uma defesa completa. As CSPs são definidas inteiramente pelo domínio de origem de onde um script é carregado e não analisam o comportamento dos scripts.
Com o cside, você pode configurar políticas que restringem o acesso dos scripts por comportamento. Ou seja, scripts específicos podem ter permissão para ler cookies ou entradas de formulário, enquanto todos os outros scripts (incluindo os aprovados) são bloqueados de executar ações arriscadas no navegador.
3. Verificar integridade, detectar alterações e configurar alertas
Seu mecanismo de rastreamento também deve monitorar alterações e atualizações nos scripts. Um script pode estar saudável e seguro em um dia e ter sua integridade comprometida com uma atualização.
Um controle nativo do navegador para isso é o Subresource Integrity (SRI). O SRI adiciona um hash criptográfico a scripts ou tags <link>. Ele funciona como uma garantia da integridade do código. Quando o navegador carrega um script, ele verifica o hash. Se um único byte for diferente, o navegador não executará o código. O SRI funciona bem para proteger ativos estáticos de terceiros e detecta modificações no nível da CDN. Mas o SRI falha com scripts dinâmicos, dos quais a maioria dos sites modernos depende.
Uma solução de fornecedor (como o cside) pode ser usada para monitorar a integridade dos scripts por meio de várias camadas de um mecanismo de detecção. As equipes de segurança são alertadas automaticamente quando há uma anomalia comportamental ou um comprometimento conhecido de um fornecedor na cadeia de suprimentos.
4. Use monitoramento em tempo de execução que analisa o comportamento dos scripts
"Scanners remotos" são fáceis de implementar, mas têm visibilidade limitada. Uma pesquisa da ISACA conclui que essas ferramentas de teste de segurança perdem ameaças onde o código é carregado condicionalmente para evitar tais varreduras. Soluções do tipo "scanner" também se limitam à detecção, com pouca capacidade de bloquear código malicioso.
Revisar código de terceiros antes da implantação em produção também tem limitações. Muitos scripts são aprovados uma vez, raramente revisados, mas mudam com frequência. Um script pode passar pela revisão antes de ser publicado e ter código malicioso inserido meses depois.
O monitoramento em tempo de execução detecta scripts comprometidos provenientes de fontes confiáveis. Quando um script de repente começa a ler campos de formulário ou fazer requisições de rede, verifique seu inventário e bloqueie-o. O monitoramento em tempo de execução observa os scripts em ação. Até mesmo aspectos como manipulação do DOM podem ser rastreados com monitoramento em tempo de execução.
Fazer isso por meio de ferramentas desenvolvidas internamente rapidamente se torna inviável. Você acaba criando seu próprio antivírus e investindo recursos pesados em um projeto que não está alinhado com o seu negócio principal. Existem diversas soluções prontas para uso, como o cside, que executam o monitoramento em tempo de execução automaticamente nas suas páginas e organizam os dados em dashboards e alertas claros.
5. Alinhamento com Conformidade
Conformidade tem reputação de gerar burocracia demorada. Controles client-side são exigidos por uma lista crescente de frameworks, incluindo GDPR, PCI DSS e CCPA/CPRA.
Certifique-se de que as atividades de processamento dos seus scripts de terceiros estejam alinhadas com as expectativas desses frameworks: transparência, limitação de finalidade e proteção de dados. Isso significa que você precisa entender exatamente como os scripts de terceiros se comportam, para que possa divulgá-los com precisão nos seus avisos de privacidade. Por padrão, os scripts devem coletar apenas os dados necessários (remetendo ao acesso com privilégio mínimo) e as salvaguardas de segurança devem proteger os usuários contra a exfiltração de dados client-side.
Um bom ponto de partida como prática recomendada é entender os DPAs de cada fornecedor terceiro que você adiciona ao seu site. Eles detalharão como pretendem processar os dados coletados dos seus usuários. Para garantir que a atividade real esteja alinhada com as expectativas, uma ferramenta de monitoramento de scripts de terceiros como o cside pode ser implantada.
Por que sites dependem de JavaScript de terceiros
É uma boa prática de negócios que os construtores não façam seus próprios tijolos, mas dependam de especialistas para materiais e engenharia. O mesmo vale para desenvolvedores web: eles usam ferramentas de terceiros para analytics, pagamentos online, widgets e outros recursos que tornam os sites dinâmicos e interativos.
Não há necessidade de reinventar soluções que já existem. Ferramentas especializadas fazem o trabalho para que as equipes web possam se concentrar no negócio principal, em vez de se preocupar com interface do usuário, testes A/B, fluxos de pagamento online, analytics, rastreamento de localização e assim por diante.
Por que scripts de terceiros representam um grande risco para a segurança client-side
O Problema de Privilégios dos Scripts de Terceiros
Eis o problema: no navegador, todo JavaScript é tratado de forma igual.
O DOM não distingue entre o seu código e o código de um fornecedor. Scripts de terceiros têm o mesmo acesso a dados do usuário e campos de formulário que o seu próprio código de primeira parte. Eles podem ler campos de formulário, acessar cookies, modificar o conteúdo da página e fazer requisições de rede.
É exatamente essa vulnerabilidade que os agentes maliciosos estão procurando.
O Problema da Cadeia de Suprimentos dos Scripts de Terceiros
Isso 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 mobile são injetados dinamicamente. No percentil 90, o número de scripts chega a até 70%. No desktop, os números são comparáveis.
Scripts injetados podem criar um ponto cego de segurança porque estão fora do perímetro das ferramentas tradicionais de segurança web. Isso também implica que scripts de terceiros injetados dinamicamente podem até injetar scripts adicionais que você nunca aprovou.
uma violação em um dos seus fornecedores = uma violação na sua aplicação
Pior ainda: um script comprometido pode se propagar por todos os sites que o utilizam. Uma única vulnerabilidade em um script amplamente usado pode se transformar em um ataque em larga escala à cadeia de suprimentos.
