O registro de atividade de scripts na camada do navegador é a gravação em tempo real do que o JavaScript executa no navegador de um usuário: cada leitura do DOM, acesso a campos de formulário, solicitação de rede, escrita de cookies e injeção dinâmica de scripts realizada por código próprio e de terceiros durante uma sessão ativa. É a camada de registro que as ferramentas SIEM, EDR e WAF não conseguem alcançar, e onde o skimming Magecart, comprometimentos da cadeia de fornecimento e scripts de sequestro de sessão se executam.
A maioria das equipes de segurança tem um registro sólido nas camadas de servidor, rede e endpoint. O runtime do navegador, onde scripts de terceiros são executados com os mesmos privilégios que o código próprio, quase sempre não é monitorado. Este guia aborda o que um log de atividade de scripts do navegador captura, por que a lacuna importa e como é a resposta eficaz a incidentes quando um script no seu site é comprometido.
A lacuna de registro que a maioria das stacks deixa aberta
Uma stack de segurança empresarial típica registra as seguintes camadas:
| Camada | O que registra | Ferramentas típicas |
|---|---|---|
| Rede | Tráfego HTTP/S, DNS, eventos de firewall | WAF, NGFW, NDR |
| Endpoint | Chamadas ao SO, execução de processos, escritas de arquivos | EDR, XDR |
| Servidor | Logs de aplicação, eventos de autenticação, chamadas de API | SIEM (via agentes/conectores) |
| Runtime do navegador | Execução de JavaScript, leituras do DOM, comportamento de scripts | Ausente na maioria das stacks |
O runtime do navegador é onde os ataques do lado do cliente operam. Um script Magecart lê o valor de um campo de cartão de pagamento e o envia para um servidor remoto. Essa leitura acontece completamente dentro do navegador. A camada de rede vê um POST HTTPS depois que os dados já saíram. O EDR não detecta nenhum processo anômalo. O SIEM não tem entrada. O ataque é concluído com logs limpos em todos os lugares, e é por isso que as equipes que querem detectar Magecart em tempo real instrumentam o próprio navegador.
Para um único GET /pricing a partir de um só IP, as duas camadas chegam a veredictos opostos:
| O que a camada de rede/servidor vê | O que a camada de sessão de navegador vê |
|---|---|
| IP: proxy residencial | Ponteiro: 0 px movidos |
| TLS: impressão digital do Chrome 124 | Permanência: 0,2 s por página |
| Cookie: sessão válida | Navegação: estritamente sequencial |
| User-Agent: Chrome 124 | Rolagem: nenhuma |
| Veredicto: sem anomalia, carregamento limpo | Veredicto: classificada como automatizada, sessão com limite de taxa |
Os cabeçalhos parecem humanos, então o WAF, a CDN e a inspeção de IP deixam a solicitação passar. A mesma sessão, lida na camada de navegador, nunca move o ponteiro, permanece 0,2 segundo por página e percorre as páginas em ordem estrita sem rolar: o ponto cego da rede é exatamente onde a cside a detecta.
O comprometimento da cadeia de fornecimento do Polyfill[.]io em junho de 2024 demonstrou isso em escala. Um script hospedado em CDN amplamente utilizado foi modificado para servir payloads maliciosos a mais de 490.000 sites. O WAF, SIEM e EDR de cada site afetado tinham logs limpos. As únicas ferramentas capazes de detectar a anomalia eram as que operavam na camada de execução do navegador.
O que um log completo de atividade de scripts do navegador captura
Um log de atividade útil na camada do navegador registra seis categorias de comportamento de scripts:
1. Acesso ao DOM e mutações
Quais elementos um script lê ou escreve, com atenção especial a campos de entrada, elementos de formulário e campos de senha. Um script na página de pagamento que nunca havia lido o campo do número do cartão anteriormente, mas o faz em uma nova implantação, é uma anomalia de comportamento que merece ser sinalizada imediatamente.
2. Solicitações de rede
Cada fetch(), XMLHttpRequest, navigator.sendBeacon(), pixel de imagem e conexão WebSocket iniciada por um script, incluindo o domínio de destino, o método de solicitação e se o destino é novo ou já visto anteriormente. Novos destinos de saída são o indicador principal de exfiltração de dados.
3. Acesso a cookies e armazenamento
Quais scripts leem ou escrevem cookies, localStorage e sessionStorage. Scripts de análise legítimos raramente precisam de tokens de sessão. Se um começar a lê-los, o comportamento deve ser sinalizado.
4. Injeção dinâmica de scripts
Scripts que criam novos elementos <script> ou usam eval(), Function() ou document.write() para executar novo código em tempo de execução. É assim que o malware de segunda etapa se carrega em ataques à cadeia de fornecimento: o primeiro script é limpo e ele busca e executa o payload real dinamicamente.
5. Solicitações de sub-recursos e dependências de quarta parte
Scripts que carregam recursos externos adicionais, criando uma cadeia do seu terceiro aprovado para um domínio de quarta parte não aprovado. O ataque do Polyfill[.]io usou esse padrão: o script CDN comprometido carregou código controlado pelo atacante de um domínio separado.
6. Desvios da linha de base de comportamento
O sinal mais acionável não é um único evento, mas um desvio do comportamento estabelecido. Um script que executou na sua página de pagamento por seis meses e nunca acessou campos de formulário, que de repente começa a ler valores de entrada de cartão em uma sessão a cada mil: esse é o evento de detecção.
Resposta a incidentes para ataques de scripts do navegador
A resposta eficaz a incidentes para o comprometimento de um script na camada do navegador segue um fluxo de trabalho distinto dos incidentes do lado do servidor. O cronograma é comprimido porque os dados podem ser exfiltrados em milissegundos e a superfície de ataque é cada sessão de usuário executando o script comprometido.
Detectar
A detecção depende de alertas de anomalias de comportamento, não de correspondência de assinaturas. A detecção baseada em assinaturas falha contra payloads polimórficos e ofuscados descritos em detalhes aqui. O gatilho para um incidente na camada do navegador deve ser: um script conhecido acessando tipos de dados que nunca havia acessado anteriormente, ou um script fazendo solicitações de rede para um destino fora do perfil de comportamento estabelecido.
Um alerta em tempo real, não um lote SIEM do dia seguinte, é o padrão mínimo. No momento em que uma revisão diária de logs detecta um script Magecart, dezenas de milhares de sessões podem ter sido expostas.
Conter
A contenção na camada do navegador acontece de forma diferente da contenção no endpoint. As opções incluem:
- Bloquear a solicitação de rede específica: impedir que a chamada de exfiltração seja concluída interceptando a solicitação de saída que o script malicioso faz.
- Bloquear o próprio script: impedir que o script comprometido seja carregado em carregamentos de página subsequentes, reduzindo imediatamente a superfície de ataque.
- Alertar sem bloquear: usar para detecções de menor confiança onde o risco de falsos positivos é alto. Registra o evento e alerta a equipe sem impacto visível para o usuário.
A capacidade de bloquear sem uma implantação de código, diretamente de uma plataforma de monitoramento sem tocar no código-fonte do site, é crítica para a velocidade de contenção. As implantações de código levam horas; o bloqueio na camada do navegador pode ser quase instantâneo.
Investigar
A etapa de investigação requer um log do que aconteceu nas sessões afetadas. Sem um log de atividade do navegador, essa etapa é quase impossível. Com um, a investigação pode responder:
- Quais sessões executaram a versão comprometida do script?
- Durante essas sessões, quais campos de dados o script acessou?
- Para onde foram enviadas as solicitações de rede?
- A exfiltração foi concluída (o destino respondeu) ou foi interrompida?
Esse log também é o registro probatório para decisões de notificação de violação sob o Artigo 33 do RGPD (limite de notificação de 72 horas) e requisitos de PCI DSS. Sem ele, a suposição padrão na maioria dos frameworks é que todas as sessões expostas foram comprometidas.
Remediar
A remediação para o comprometimento de um script do navegador inclui: remover ou reverter a versão comprometida do script, confirmar que o endpoint de exfiltração do atacante está bloqueado no nível de rede, avaliar quais sessões de usuário requerem notificação e atualizar a linha de base de comportamento do script para que o próximo desvio seja detectado mais rapidamente.
A revisão pós-incidente deve avaliar se a janela de detecção a contenção atendeu a um limite aceitável. Para scripts em páginas de pagamento sob os requisitos de PCI DSS 6.4.3 e 11.6.1, a expectativa é detecção de modificações não autorizadas de scripts em tempo real, não horas ou dias depois.
Como avaliar plataformas para registro de atividade de scripts do navegador
Nem todas as ferramentas de monitoramento que afirmam ter visibilidade na camada do navegador realmente instrumentam o runtime do navegador. Perguntas a fazer durante a avaliação de um produto:
| Área de avaliação | O que procurar | Sinal de alerta |
|---|---|---|
| Método de registro | Agente ou SDK que roda no navegador e observa a execução | Crawler que simula sessões externamente |
| Cobertura | Todas as sessões, não um subconjunto amostrado | Amostragem significa que a maioria dos ataques não é registrada |
| Aprendizado de linha de base | Perfil de comportamento automático por script por página | Requer configuração manual de limites |
| Capacidade de bloqueio | Pode bloquear solicitações de rede de scripts sem implantação de código | Apenas detecção sem caminho de aplicação |
| Retenção de logs | Logs indexados em nível de sessão disponíveis para investigação | Apenas métricas agregadas, sem replay de sessão |
| Evidência de conformidade | Logs exportáveis mapeados para PCI DSS 6.4.3/11.6.1 e Artigo 32 do RGPD | Sem saída de conformidade estruturada |
A distinção principal é o método de instrumentação. Um scanner externo visita sua página a partir de um navegador headless e registra o que observa durante aquela sessão artificial. Um atacante que só ativa contra usuários reais, uma técnica de evasão comum, é invisível para um scanner. A instrumentação em tempo de execução que roda em cada sessão de usuário real captura o que os scanners perdem.
Onde o cside se encaixa
O cside é o registro de atividade de scripts nativo do navegador e a aplicação construída especificamente para o risco de JavaScript de terceiros. Ele instrumenta a camada de execução do navegador em cada sessão de usuário real e registra as seis categorias descritas acima: acesso ao DOM, solicitações de rede, leituras de cookies e armazenamento, injeção dinâmica de scripts, cadeias de sub-recursos e desvios de comportamento das linhas de base estabelecidas.
Quando uma anomalia é detectada, o cside pode bloquear as solicitações de rede do script ou o próprio script sem exigir uma implantação de código. O log de atividade que produz é estruturado tanto para investigação de incidentes quanto para evidência de conformidade sob PCI DSS 6.4.3, 11.6.1 e Artigo 32 do RGPD.
Para equipes que atualmente dependem da cobertura de SIEM, EDR e WAF e assumem que essas três camadas cobrem toda a superfície de ataque: elas não cobrem o runtime do navegador. Essa é a camada onde operam Magecart, formjacking e digital skimming, comprometimentos da cadeia de fornecimento e scripts de sequestro de sessão, e é a camada onde o registro de atividade de scripts e a resposta a incidentes tem a maior lacuna na maioria das stacks empresariais.
