Resumo: porquê os sites ainda carregam JavaScript de terceiros
- A auto-hospedagem não resolve: Não é possível resolver isto apenas com auto-hospedagem. Muitos scripts de terceiros servem payloads diferentes por user agent, por IP ou por região/idioma, por isso, ao trazê-los para a sua origem, está a entregar uma única cópia desatualizada em vez do conjunto completo de que os seus visitantes realmente precisam.
- A cside lê cada payload: O pacote npm do Intercom carrega uma frota de scripts em tempo de execução e o @monaco-editor/react totaliza mais de 712.000 downloads semanais enquanto carrega um script de terceiros. O agente JavaScript first-party da cside observa o comportamento em tempo de execução de cada script no navegador e desmonta cada payload ao nível do AST.
- O CSP confia em domínios, não em código: Se a sua CSP é todo o seu plano de cadeia de fornecimento, tem uma política que confia em domínios, não em código. Decida qual dos dois realmente precisa de conhecer.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Como os scripts de terceiros entram num site
Ao desenvolver um site, é frequente incluir bibliotecas para ajudar a acelerar o processo de desenvolvimento e evitar reinventar a roda. No entanto, há momentos em que é preciso carregar um script a partir de uma fonte externa. Ataques recentes como a apropriação do domínio Polyfill levantam uma questão óbvia: porque é que, afinal, precisamos de scripts de terceiros, e como é que eles acabam num site?
Antes de mais, vamos contextualizar. Scripts de terceiros são ficheiros JavaScript servidos a partir de um servidor que não é o nosso. Por exemplo, suponhamos que administro o meu site, cside.com. Este site foi criado por uma equipa de desenvolvedores, que usaram várias bibliotecas para o montar. Isto é depois compilado / transformado / dividido em ficheiros JavaScript mais pequenos e em menor número do que o código-fonte original. É a isto que chamamos JavaScript first-party (de primeira parte) - é servido como um recurso dentro de cside.com, por exemplo cside.com/_next/static/chunks/main-ab76c1828cff9b09.js.
Uma semana depois, um membro da equipa de marketing pede aos desenvolvedores que adicionem ao site um script para a ferramenta de análise que escolheram. Agora, o site tem o seu primeiro JavaScript de terceiros. Este processo pode continuar, com a equipa jurídica a pedir um banner de cookies, o marketing a pedir outro script de análise, e assim sucessivamente.
Os desenvolvedores conhecem os riscos do JavaScript de terceiros, por isso pesquisam a ferramenta online, fazem alguma investigação e consideram-na fiável.
Este ciclo repete-se até haver uma dezena de scripts ou mais na página. Todos legítimos, todos importantes e todos de terceiros. No pior dos casos, um destes domínios é adquirido, é servido tráfego malicioso e o site fica infetado.
Mas isto é um exagero - e não é, geralmente, assim que os ataques acontecem na prática. Os scripts de nível superior no seu site normalmente não são os alvos, embora isso seja possível (veja aqui a nossa análise sobre o Polyfill). Frequentemente, os scripts carregam outros scripts. Alguns scripts podem até criar iframes e carregar ainda mais scripts. Tal como o seu código first-party utiliza várias dependências, os scripts de terceiros também têm requisitos para se tornarem funcionais, e têm a sua própria cadeia de fornecimento.
Por vezes, até as bibliotecas first-party que adicionamos podem carregar um script durante a execução. Podem fornecer um componente React prático para colocar na página, mas, por trás, estão a adicionar alguns scripts para se tornarem funcionais. Seja a carregar localização, as suas próprias análises, temas ou outra coisa - estão a acrescentar à cadeia de fornecimento de terceiros do seu site.
Por isso, pode pensar: porque não simplesmente descarregar estes scripts e hospedá-los nós próprios? Para alguns scripts básicos, como o jQuery, esta é uma escolha óbvia - e uma que recomendamos. Se estiver a lidar com um script estático na cadeia de fornecimento do seu site, traga-o para a sua origem, se possível.
No entanto, muitos scripts servem conteúdo dinâmico com base no requisitante. Por exemplo, podem verificar o User Agent no pedido e decidir que precisa de uma versão diferente com funcionalidades extra. Ou podem verificar o seu IP e decidir enviar-lhe uma localização diferente do script.
Estes ainda são estáticos por utilizador na maioria das vezes, mas, importa notar, não são estáticos globalmente. Isto significa que, ao servir o script por conta própria, estaria apenas a servir uma variação, e não o conjunto completo de scripts necessário para proporcionar aos seus utilizadores a melhor experiência.
Alguns scripts podem até ter URLs fixas (hard-coded) para sub-scripts que irão carregar. Isto significa que, mesmo que copie o script raiz para o seu site, ele continuará a carregar scripts externos a partir de uma URL remota.
Até bibliotecas que possa estar a usar todos os dias na sua aplicação seguem este padrão. Vejamos alguns exemplos:
O pacote npm do Intercom carrega uma série de scripts em tempo de execução:
https://developers.intercom.com/installing-intercom/web/installation#single-page-app
Mesmo ao usar ferramentas de rastreio de redes sociais, que são inevitáveis para a maioria das empresas que fazem marketing em redes sociais, a primeira coisa que os scripts fornecidos fazem é carregar outro script de terceiros:
Ou então usa um pacote React como o @monaco-editor/react, com mais de 712.000 downloads semanais, que carrega um script de terceiros para grande parte da sua funcionalidade: https://www.npmjs.com/package/@monaco-editor/react
Então, para onde vamos a partir daqui? É por isso que a cside existe. Fazemos o proxy de todos os scripts carregados na página - mesmo os que são carregados durante a execução. Reescrevemos as URLs dos scripts para que a cside os obtenha primeiro, que é capaz de bloquear um script antes mesmo de este ser servido ao cliente.
A cside oferece um ponto de vista único: permite políticas por URL, por domínio, por hash e por cabeçalhos, que podem ser implementadas globalmente em segundos. Se qualquer script tentar carregar um script-filho, a cside saberá disso e analisá-lo-á. E depois dá-lhe o controlo para decidir o que acontece: permitir este script, bloquear este script, e a recolha de dados analíticos que o acompanha.
Para cada script que a cside vê, entregamo-lo ao nosso motor de deteção. O nosso motor de deteção desmonta o script - até ao nível do AST - para descobrir o que faz. E fazemos isto para cada pequena alteração num script, mesmo que seja apenas um caráter. Podemos informá-lo sobre o que um script está a fazer, quando o seu acesso ao seu site muda, e toda uma série de informações de confiança sobre a origem.
Temos analistas de segurança a trabalhar 24 horas por dia para detetar ameaças emergentes e bloqueá-las na nossa camada de proxy antes de estas chegarem a afetar algum dos seus clientes. Combine isto com o motor de deteção automática já mencionado, e passará a ter controlo total sobre a cadeia de fornecimento de terceiros do seu site.
Pode inscrever-se no nosso plano gratuito aqui.
A cadeia de fornecimento do navegador interessa-lhe? Se sim, junte-se a nós nesta missão de proteger todos os utilizadores da World Wide Web: https://cside.com/careers
