Riscos de segurança de scripts JavaScript de terceiros

Em sua palestra sobre segurança na web na SnykCon 2020, Liran Tal e Eric Graham discutiram considerações de segurança de front-end relacionadas à superfície de ataque. Eles apresentaram os riscos decorrentes de vulnerabilidades de segurança em dependências de terceiros e, em seguida, ampliaram a discussão para incluir os riscos potenciais de scripts de terceiros adicionados pelo marketing, como o Google Tag Manager.

Neste artigo, analisamos os riscos de segurança causados por scripts de marketing adicionados a um site, como serviços de teste A/B, Google Analytics e outros, e mostramos como reduzi-los.

Play Video: Securing Front-end Attack Surfaces - Eric Graham and Liran Tal

Quais são os riscos de segurança de scripts de terceiros para a segurança na web?

Para responder a essa pergunta, no vídeo Eric Graham explora, passo a passo, a inclusão de código de terceiros em aplicações web e sites estáticos. Ele mostra em que medida esses sites incluem código-fonte de diferentes fornecedores e mantenedores de projetos open source.

Como você pode ver, o código escrito pelos desenvolvedores da sua equipe representa apenas uma pequena parte de todo o código entregue aos seus clientes. Ao lado dele, há scripts para testes A/B ou de usabilidade, além de atividades de marketing e vendas, como segmentação de usuários ou otimização do funil de vendas.

Como e por que scripts de terceiros são adicionados a um site?

Para piorar, eles costumam ser adicionados por profissionais de marketing e gerentes de web, fora do ciclo de vida de desenvolvimento de software e do pipeline de CI/CD, ignorando completamente a revisão de código e os testes dos desenvolvedores. O software usado para isso é chamado de gerenciador de tags. Entre os fornecedores mais conhecidos estão o Google (GTM) e a Adobe, com o Launch (sucessor do Dynamic Tag Manager, ou DTM).

Esses gerenciadores de tags, por sua vez, carregam outros scripts, abrindo ainda mais conexões HTTP com domínios diferentes. Esses domínios podem ser invadidos, levando à implantação de malware. Isso nos leva ao universo da malvertising, por assim dizer.

Profissionais de marketing e engenharia de analytics usam regularmente scripts JavaScript de terceiros para ampliar os recursos de um site, impulsionar o crescimento, segmentar usuários e melhorar o funil de vendas. Um exemplo popular é a ferramenta GTM ou o Launch da Adobe, que representa um grande avanço em relação ao antecessor, o Dynamic Tag Manager (DTM).

Como esses scripts têm impacto nos resultados de marketing, as equipes de marketing de produto e analytics tendem a priorizar a experimentação rápida e a inclusão de scripts adicionais em sites ou aplicações web.

Esses scripts de marketing de terceiros passam por auditorias de segurança?

As equipes se lembram de remover os scripts de terceiros da aplicação web quando terminam de usá-los? Muitas vezes, isso não é garantido e pode acabar passando despercebido. Assim, você pode estar executando código não confiável sem nem saber!

A inclusão de scripts JavaScript de terceiros em uma página web contorna completamente o pipeline de DevOps e todos os processos ou diretrizes de segurança definidos durante o desenvolvimento.

Além disso, como são injetados diretamente no DOM, os terceiros recebem acesso a todos os recursos que também estão à disposição dos seus desenvolvedores. Isso pode causar grandes danos aos seus clientes.

A imprensa noticiou vários incidentes de segurança envolvendo a injeção maliciosa de scripts JavaScript de terceiros em aplicações web e até mesmo como hackers escondem um skimmer web nos arquivos CSS de um site. Esses casos vêm na esteira de incidentes anteriores de segurança relacionados a scripts Magecart embutidos em favicons, mensagens de chat ao vivo e botões de compartilhamento em redes sociais.

É possível resolver os riscos de segurança do JavaScript de terceiros?

Para resolver nossas preocupações com a segurança do JavaScript, vamos explorar maneiras melhores de dar suporte ao JavaScript de terceiros na base de código de um site e, assim, reduzir ou mitigar os riscos de segurança.

Abordagens técnicas

Uma opção é incluir o JavaScript de terceiros em um iFrame e restringir seu acesso usando os atributos allow e/ou sandbox. Tenha em mente que isso pode impedir o funcionamento esperado.

Outra alternativa é aplicar integridade de subrecursos (SRI), mas isso exige que o fornecedor desses scripts compartilhe os valores de hash das bibliotecas distribuídas. Porém, o conteúdo costuma ser personalizado e, portanto, dinâmico.

O grupo de trabalho W3C propôs um padrão para coletar métricas de comportamento dos usuários e atender a outras necessidades no seguinte documento: Customer Experience Digital Data Layer 1.0. A seção 6.11 define quais grupos de scripts de terceiros podem acessar determinados tipos de dados. No entanto, a aplicação dessa regra fica a cargo de quem mantém a camada de dados.

Abordagens culturais

Como as abordagens técnicas não são suficientes, vamos explorar as culturais.

O marketing deveria fazer parte do ciclo de vida de desenvolvimento de software e enviar suas alterações por um pipeline de DevOps? A colaboração com engenheiros é ideal, mas pode ser difícil conciliá-la com as prioridades de negócio e a comunicação entre departamentos.

Você monitora ativamente todas as solicitações HTTP feitas pela sua aplicação web ou pelo seu domínio? Você pode usar ferramentas como o Page Integrity Manager da Akamai ou a ferramenta web gratuita e open source WebPageTest para monitorar solicitações HTTP e até integrá-la ao pipeline de integração contínua (CI).

Por fim, a cultura da organização pode ajudar a promover uma mentalidade que priorize a privacidade entre engenheiros e profissionais de marketing ao implementar analytics e outros componentes JavaScript de terceiros.

Conclusão

A superfície de ataque do front-end é ampla: começa no código-fonte da sua própria aplicação web e nas dependências, e se estende aos scripts de terceiros adicionados fora do processo de desenvolvimento.

Além de adotar abordagens técnicas, busque uma mudança cultural para se manter seguro na internet.

Para saber mais, confira estes recursos:

1. Explore a tendência da arquitetura orientada a eventos, detalhada por Jim Gordon em sua publicação no blog: https://jimalytics.com/tag-management/the-event-driven-data-layer.

2. Leia o blog de Jan Exner em https://webanalyticsfordevelopers.com, onde ele explica analytics para desenvolvedores de uma forma que faz sentido para engenheiros.

3. Assista à palestra Securing Frontend Attack Surfaces da SnykCon, que mostra a dimensão desse risco de segurança.