Resumo: porque não deve implementar scripts de análise em todo o site
- A conveniência gerou fuga: Os documentos de onboarding continuam a dizer aos programadores para colarem tags de análise no _document.js e a avançarem, mas foi precisamente essa conveniência que levou a Kaiser Permanente a enviar 13,4 milhões de registos de membros a fornecedores terceiros que nunca deveriam tê-los visto.
- PCI torna obrigatório: O PCI DSS 4.0 torna o inventário e a integridade dos scripts obrigatórios até março de 2025. O agente JavaScript first-party da cside observa o comportamento em tempo de execução de cada script de terceiros em 100% das sessões, em todas as páginas, com bloqueio autónomo por cima.
- Delimite antes de auditar: Antes da próxima auditoria de framework, decida se os pixéis de análise e marketing precisam mesmo de acesso ao DOM nas suas páginas de login, KYC e conta, ou se uma implementação limitada à página fecha, sem custos, um vetor de ataque à cadeia de fornecimento.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Os scripts de terceiros são frequentemente implementados em todo o site, normalmente injetados nas tags head em frameworks web como o Next.js através do ficheiro '_document.js'. Esta implementação generalizada, embora conveniente para os programadores e muitas vezes recomendada pelos guias de onboarding, significa que estes scripts são executados em todo o site. É mais simples de implementar, mas também introduz riscos de segurança e problemas de desempenho que costumam ser ignorados.
A recente fuga de dados da Kaiser Permanente mostra os perigos de ter scripts de terceiros mal geridos. Como escrevemos na nossa análise completa do incidente:
A 29 de abril, a gigante da saúde Kaiser Permanente divulgou uma fuga de dados que afetou 13,4 milhões de membros atuais e antigos do seguro. O incidente teve origem em scripts de terceiros geridos de forma inadequada. A Kaiser Permanente utilizava códigos de rastreio para monitorizar a forma como os membros navegavam no seu site e nas aplicações móveis. Algumas destas páginas continham dados de saúde sensíveis, o que levou os scripts de terceiros a transmitir inadvertidamente informação a fornecedores terceiros que não deveriam ter acesso a ela. Embora a violação não tenha resultado de um sequestro de script, ela evidencia uma falha significativa na gestão de scripts de terceiros.
Mas o problema é mais amplo do que a fuga de informação potencialmente sensível para fornecedores terceiros. Os scripts de terceiros são usados por todo o lado, mas raramente são examinados, monitorizados ou protegidos.
Os riscos de implementar scripts de terceiros em todo o site
Vejamos agora alguns dos problemas que surgem quando se implementam scripts globalmente.
1. Acesso descontrolado a dados
Foi isto que aconteceu no caso da Kaiser Permanente. Os scripts de terceiros implementados globalmente têm frequentemente acesso a dados sensíveis nas páginas web. Isto pode incluir dados introduzidos pelo utilizador, informação de sessão e outros dados confidenciais. Sem controlos rigorosos, estes scripts podem, de forma inadvertida ou maliciosa, deixar escapar dados para partes não autorizadas. No caso da Kaiser Permanente e de outras entidades de saúde, os scripts de terceiros frequentemente não cumprem a Health Insurance Portability and Accountability Act (HIPAA), o que torna uma fuga de dados para esses fornecedores um incidente grave.
2. Ataques à cadeia de fornecimento
Os atacantes podem comprometer a cadeia de fornecimento web ao visarem serviços de terceiros e injetarem código malicioso nos scripts. Estes scripts comprometidos podem depois propagar malware, roubar dados ou realizar outras ações prejudiciais em todos os sites onde estão implementados. Isto já é grave por si só, mas piora ainda mais quando os scripts são implementados globalmente e têm acesso a mais dados e utilizadores.
Como é evidente, a cside protege contra isto.
3. Aplicações Web de Página Única (SPAs)
As SPAs não lidam nada bem com scripts. A menos que o programador force uma atualização completa da página ao navegar para uma página sensível, todos os scripts previamente carregados permanecem presentes. Qualquer script de terceiros carregado inicialmente continua em execução e pode potencialmente aceder a dados sensíveis durante toda a sessão do utilizador, a não ser que a página seja completamente atualizada, o que aumenta o risco de fugas de dados e acessos não autorizados.
4. Riscos de conformidade e regulamentação
As organizações têm de cumprir diversas regulamentações de proteção de dados, como o RGPD, a HIPAA e o PCI DSS 4.0. Uma gestão inadequada dos scripts de terceiros pode levar ao incumprimento, o que arrisca coimas avultadas e consequências legais.
O PCI DSS 4.0 exige a monitorização de scripts de terceiros até março de 2025, pelo que é agora o momento de começar e de implementar a cside. Isto garante-lhe a conformidade e acrescenta bloqueio autónomo para se proteger ainda mais.
5. Problemas de desempenho e estabilidade
Talvez menos evidente, mas definitivamente percetível, scripts de terceiros mal otimizados tornam os sites mais lentos. Qualquer indisponibilidade ou problema no serviço de terceiros pode afetar diretamente a funcionalidade e a disponibilidade do site que os aloja. Um site que carrega em 1 segundo tem uma taxa de conversão 3x superior à de um site que demora 5 segundos a carregar.
Proteja-se contra estes problemas
Tal como as diretrizes do PCI DSS 4.0, somos defensores da monitorização contínua de segurança e incentivamos todos os proprietários de sites a adotá-la. Acreditamos que aplicá-la a todas as páginas é a abordagem mais eficaz.
Pode fazê-lo utilizando o nosso plano gratuito. É self-service, deixando-o em conformidade e seguro em minutos. Como é óbvio, estamos sempre por perto para ajudar sempre que necessário.
O nosso script reescreve as origens dos outros scripts do seu site para os canalizar através da cside. Também realiza algumas deteções do lado do browser. Isto permite que a cside faça a mediação do fluxo de pedidos entre o utilizador e o script de terceiros sem acrescentar latência. Em alguns casos, pode até melhorar o desempenho ao colocar em cache scripts estáticos.
Isto dá visibilidade total sobre todos os scripts servidos, em 100% das sessões, em todas as páginas.
Para mais informações sobre em que difere a nossa abordagem, leia aqui.
