Como scripts de terceiros entram em um site
Ao desenvolver um site, você frequentemente incluirá bibliotecas para ajudar a acelerar o processo de desenvolvimento e evitar reinventar a roda. No entanto, há momentos em que você precisa carregar um script de uma fonte externa. Devido a ataques recentes como a apropriação do domínio Polyfill, questões foram levantadas: por que você precisa de scripts de terceiros? Como eles acabam em um site?
Primeiro, vamos contextualizar. Scripts de terceiros são arquivos JavaScript servidos de um servidor diferente do seu. Por exemplo, suponha que eu administre meu site, cside.com. Este site foi criado por uma equipe de desenvolvedores, que usaram várias bibliotecas para montá-lo. Isso é então compilado / transformado / dividido em arquivos JavaScript menores e em menor quantidade do que o código-fonte originalmente era composto. Isso é o que chamamos de JavaScript de primeira parte – ele é servido como um recurso dentro de cside.com, por exemplo cside.com/_next/static/chunks/main-ab76c1828cff9b09.js.
Uma semana depois, um membro da equipe de marketing pede aos desenvolvedores que adicionem um script ao site para seu produto de análise de escolha. Agora, o site tem seu primeiro JavaScript de terceiros. Este processo pode continuar com a equipe jurídica pedindo um banner de cookies, marketing pedindo outro script de análise, e assim por diante.
Os desenvolvedores conhecem os riscos do JavaScript de terceiros, então eles pesquisam online sobre a ferramenta, fazem algumas pesquisas e a consideram confiável.
Este ciclo se repete até que haja uma dúzia de scripts ou mais na página. Todos legítimos, todos importantes e todos de terceiros. No pior caso, um desses domínios é comprado, tráfego malicioso é servido e seu site fica infectado.
Mas isso é um exagero – e não é assim que os ataques geralmente acontecem. Os scripts de nível superior em seu site geralmente não são os que são alvos, embora isso seja possível (veja nossa análise sobre Polyfill aqui). Frequentemente, scripts carregam outros scripts. Alguns scripts podem até criar iframes e carregar ainda mais scripts. Assim como seu código de primeira parte usa várias dependências, scripts de terceiros também têm requisitos para se tornarem funcionais e têm sua própria cadeia de suprimentos.
Às vezes, até bibliotecas de primeira parte que você adiciona podem carregar um script durante a execução. Elas podem fornecer um componente React prático para inserir em sua página, mas nos bastidores estão adicionando alguns scripts para se tornarem funcionais. Seja carregando localização, suas próprias análises, temas ou mais - está adicionando à cadeia de suprimentos de terceiros do seu site.
Então você pode pensar: por que não simplesmente baixar esses scripts e hospedá-los você mesmo? Para alguns scripts básicos, como jQuery, esta é uma escolha óbvia - e uma que recomendamos. Se você está lidando com um script estático na cadeia de suprimentos do seu site, traga-o para sua origem, se possível.
No entanto, muitos scripts servem conteúdo dinâmico baseado no solicitante. Por exemplo, eles podem olhar seu User Agent na solicitação e decidir que você precisa de uma versão diferente com recursos extras. Ou, eles podem olhar seu IP e decidir enviar uma localização diferente do script.
Estes ainda são estáticos por usuário na maioria das vezes, mas importante não são estáticos globalmente. Isso significa que ao servir o script você mesmo, você estaria servindo apenas uma variação, não o conjunto completo de scripts necessários para dar aos seus usuários a melhor experiência.
Alguns scripts podem até ter URLs codificadas para sub-scripts que eles carregarão. Isso significa que mesmo se você copiar o script raiz para seu site, ele ainda carregará scripts externos de uma URL remota.
Até bibliotecas que você pode estar usando todos os dias em seu aplicativo seguem esse padrão. Vamos dar uma olhada em alguns exemplos:
O pacote npm do Intercom carrega vários scripts em tempo de execução:
https://developers.intercom.com/installing-intercom/web/installation#single-page-app
Mesmo ao usar ferramentas de rastreamento de mídia social, que são inevitáveis para a maioria das empresas que fazem marketing em mídias sociais, a primeira coisa que os scripts que eles fornecem fazem é carregar outro script de terceiros:
Ou, você usa um pacote React como @monaco-editor/react, com mais de 712.000 downloads semanais, que carrega um script de terceiros para grande parte de sua funcionalidade: https://www.npmjs.com/package/@monaco-editor/react
Então, para onde vamos a partir daqui? É por isso que o cside existe. Nós fazemos proxy de cada script que carrega na página - até mesmo aqueles carregados durante a execução. Reescrevemos URLs de scripts para passar pelo nosso Proxy cside, que é capaz de bloquear um script antes mesmo de ser servido ao cliente.
Nosso proxy oferece um ponto de vista único: permitindo política por url, por domínio, por hash, por cabeçalhos que pode ser implantada globalmente em segundos. Se qualquer script tentar carregar um script filho, o cside saberá sobre isso e fará proxy dele. E então lhe dará o controle para decidir o que acontece: permitir este script, bloquear este script, e as análises que o acompanham.
Para cada script que nosso proxy vê, nós o entregamos ao nosso mecanismo de detecção. Nosso mecanismo de detecção desmonta o script - até o nível AST - para descobrir o que ele faz. E fazemos isso para cada pequena mudança em um script, mesmo que seja um caractere. Podemos informá-lo sobre o que um script está fazendo, quando seu acesso ao seu site muda, e uma série de informações de confiança sobre a fonte.
Temos analistas de segurança trabalhando 24 horas por dia para detectar ameaças emergentes e bloqueá-las em nossa camada de proxy antes que elas impactem um de seus clientes. Combine isso com o mecanismo de detecção automática mencionado anteriormente, e agora você tem controle total sobre a cadeia de suprimentos de terceiros do seu site.
Você pode se inscrever para nosso plano gratuito aqui.
A cadeia de suprimentos do navegador te interessa? Se sim, venha se juntar a nós na missão de proteger cada usuário da World Wide Web: https://cside.com/careers
