Vazamentos de CDP no Puppeteer: como os sistemas antifraude detectam a automação por meio do Chrome DevTools Protocol

O que é CDP e por que ele deixa rastros digitais?

O Chrome DevTools Protocol fornece acesso de baixo nível à arquitetura do navegador. Ele foi originalmente projetado para depuração, inspeção e análise de perfil, não para raspagem furtiva de dados.

O protocolo opera por meio de conexões WebSocket que interagem diretamente com o motor V8. Quando seu script envia um comando, como um clique ou navegação de página, o navegador abre um socket local para comunicação bidirecional. Esse processo inevitavelmente gera logs internos, afeta a alocação de memória e deixa vestígios no ambiente isolado do navegador. Sistemas de segurança podem analisar essas microalterações e padrões temporais para detectar comportamento automatizado. Como resultado, a mera existência da conexão pode revelar automação do navegador.

Como os vazamentos de CDP diferem do fingerprinting tradicional

É importante entender que os vazamentos de CDP e os vazamentos de impressão digital do navegador representam dois vetores de detecção fundamentalmente diferentes.

• O fingerprinting tradicional (Canvas, WebGL, Fontes) identifica características exclusivas de hardware e comportamento de renderização. Inconsistências de impressão digital ou erros de falsificação permitem que os sistemas antibot detectem manipulação e classifiquem o usuário como suspeito.

• Os vazamentos de CDP revelam indicadores comportamentais e estruturais de execução de código. Eles expõem o fato de que o navegador está sendo controlado remotamente.

Você pode ter uma impressão digital de WebGL perfeitamente única, mas sinalizações de automação podem invalidar instantaneamente essa vantagem. As verificações de impressão digital do navegador exigem recursos e tempo de processamento consideráveis, ao passo que verificar variáveis de ambiente ou pilhas de chamadas é quase gratuito. É exatamente por isso que os sistemas antifraude preferem a detecção baseada em CDP. Isso permite filtrar bots durante verificações básicas no nível do protocolo, economizando recursos do servidor que seriam gastos em análises comportamentais profundas e mais caras.

Anatomia dos vazamentos do Chrome DevTools Protocol

Marcadores de Contexto de Execução

Uma das principais fraquezas do Puppeteer reside em como exatamente ele executa seu código dentro do navegador. Nos bastidores, o método page.evaluate() depende do comando CDP Runtime.evaluate.

Quando um script é injetado no navegador, as versões modernas do Puppeteer geram uma URL de Origem específica associada àquele fragmento de código. Se ocorrer um erro durante a execução do script, o motor V8 cria um rastreamento de pilha (stack trace) padrão que pode conter entradas como:

at pptr:evaluate;C:\Users\Admin\Projects\...\main.js:17:14

at pptr:evaluate;C:\Users\Admin\Projects\...\main.js:17:14

Ao substituir funções básicas do navegador, os sistemas antifraude podem acionar intencionalmente erros invisíveis e inspecionar o objeto Error.stack. Eles podem descobrir:

• O prefixo pptr:, uma referência direta ao Puppeteer.

• Um caminho absoluto para um arquivo em sua máquina local ou servidor, começando com C:\ ou /var/www/....

O navegador de um usuário real nunca executa código de caminhos do sistema de arquivos local ao visitar um site público. Portanto, tais marcadores representam evidências definitivas de automação.

Alterar seu endereço IP ou falsificar as impressões digitais do Canvas não resolverá esse problema. Para ocultar esses marcadores, você deve modificar a própria biblioteca ou o ambiente de execução do navegador.

A solução mais confiável é remover o marcador pptr:evaluate diretamente do código-fonte do Puppeteer antes que os comandos sejam enviados ao navegador. Como pesquisar e editar arquivos manualmente após cada instalação do npm é impraticável, um patcher simples pode ser usado:

const fs = require('fs');
const path = require('path');

// Caminho para ExecutionContext.js nas versões recentes do Puppeteer
const targetFile = path.resolve(__dirname, 'node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js');

if (fs.existsSync(targetFile)) {
    let content = fs.readFileSync(targetFile, 'utf8');
    // Substitui o prefixo pptr:evaluate por uma chamada anônima
    // e remove o caminho de arquivo local
    const patchedContent = content.replace(/pptr:evaluate;.*?\\n/g, 'anonymous:evaluation;\n');
    fs.writeFileSync(targetFile, patchedContent, 'utf8');
    console.log('Puppeteer corrigido com sucesso. Marcadores pptr:evaluate removidos.');
}

const fs = require('fs');
const path = require('path');

// Caminho para ExecutionContext.js nas versões recentes do Puppeteer
const targetFile = path.resolve(__dirname, 'node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js');

if (fs.existsSync(targetFile)) {
    let content = fs.readFileSync(targetFile, 'utf8');
    // Substitui o prefixo pptr:evaluate por uma chamada anônima
    // e remove o caminho de arquivo local
    const patchedContent = content.replace(/pptr:evaluate;.*?\\n/g, 'anonymous:evaluation;\n');
    fs.writeFileSync(targetFile, patchedContent, 'utf8');
    console.log('Puppeteer corrigido com sucesso. Marcadores pptr:evaluate removidos.');
}

Se a modificação do node_modules não for uma opção, os marcadores podem ser filtrados em tempo de execução injetando um script de falsificação antes do carregamento da página de destino. O script substitui o comportamento do objeto nativo Error e higieniza os rastreamentos de pilha:

await page.evaluateOnNewDocument(() => {
    // Salva o construtor Error original
    const NativeError = window.Error;

    window.Error = function(...args) {
        const err = new NativeError(...args);
        const originalStack = err.stack;

        if (originalStack) {
            Object.defineProperty(err, 'stack', {
                get: function() {
                    // Divide o rastreio da pilha em strings e remove as entradas relacionadas ao Puppeteer
                    return originalStack
                        .split('\n')
                        .filter(line => !line.includes('pptr:evaluate'))
                        .join('\n');
                }
            });
        }
        return err;
    };
    
    // Restaura a cadeia de protótipos para evitar detecção
    window.Error.prototype = NativeError.prototype;
});

await page.evaluateOnNewDocument(() => {
    // Salva o construtor Error original
    const NativeError = window.Error;

    window.Error = function(...args) {
        const err = new NativeError(...args);
        const originalStack = err.stack;

        if (originalStack) {
            Object.defineProperty(err, 'stack', {
                get: function() {
                    // Divide o rastreio da pilha em strings e remove as entradas relacionadas ao Puppeteer
                    return originalStack
                        .split('\n')
                        .filter(line => !line.includes('pptr:evaluate'))
                        .join('\n');
                }
            });
        }
        return err;
    };
    
    // Restaura a cadeia de protótipos para evitar detecção
    window.Error.prototype = NativeError.prototype;
});

Como resultado, em vez de expor caminhos de arquivos locais, o rastreamento de pilha exibirá algo parecido com isto

Vulnerabilidades de Page.addScriptToEvaluateOnNewDocument

As tentativas de ocultar a automação do navegador, incluindo o uso de plugins furtivos populares, geralmente dependem da injeção de falsificação de JavaScript antes que o site de destino seja carregado. No Puppeteer, isso geralmente é feito por meio do comando Page.addScriptToEvaluateOnNewDocument.

No entanto, o uso deste método por si só deixa vestígios claros no ambiente de execução.

1. Anomalias temporais. O comando força o motor V8 a executar seu código de forma síncrona quando o contexto da página é criado, antes do analisador HTML iniciar seu trabalho. A injeção de scripts grandes introduz microatrasos mensuráveis durante a fase document_start. Sistemas antifraude medem o intervalo de tempo entre os eventos internos do navegador e podem detectar essas lacunas não naturais.

2. Violações do ciclo de vida. Plugins furtivos não podem simplesmente remover sinalizadores de automação; em vez disso, eles contam com interceptações (hooks) e substituições complexas. Sistemas de proteção podem detectar que objetos proxy complexos e propriedades substituídas surgiram no objeto window de forma incomum e precoce, antes do evento DOMContentLoaded ou mesmo antes da tag <head> ter sido analisada. Isso quebra o ciclo de vida natural da página.

3. Falta de isolamento. Qualquer script injetado por meio do comando CDP addScriptToEvaluateOnNewDocument é executado no contexto principal de execução da página. Como resultado, seu código de falsificação e os scripts antifraude do site compartilham o mesmo ambiente. O menor erro ou uma variável exposta acidentalmente pode ser suficiente para o sistema de proteção detectar a automação.

Você não pode abandonar completamente a falsificação, mas pode alterar a forma como o código de falsificação é entregue. Em vez de injetar código através do protocolo de depuração, você pode usar o sistema de extensões nativo do navegador.

Os navegadores foram projetados para permitir que extensões injetem código com segurança. Se você empacotar sua lógica de falsificação em uma extensão Manifest V3 e carregá-la ao iniciar o Puppeteer, os sistemas antifraude perceberão o tempo e as injeções como o comportamento normal de uma extensão de navegador.

Por exemplo, você pode criar um diretório stealth-extension contendo um arquivo manifest.json:

{
  "manifest_version": 3,
  "name": "My Custom Stealth",
  "version": "1.0",
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["inject.js"],
      "run_at": "document_start",
      "world": "MAIN"
    }
  ]
}

{
  "manifest_version": 3,
  "name": "My Custom Stealth",
  "version": "1.0",
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["inject.js"],
      "run_at": "document_start",
      "world": "MAIN"
    }
  ]
}

E carregá-lo ao iniciar o Puppeteer em vez de chamar evaluateOnNewDocument:

const browser = await puppeteer.launch({
  args: [
    `--disable-extensions-except=${pathToExtension}`,
    `--load-extension=${pathToExtension}`
  ]
});

const browser = await puppeteer.launch({
  args: [
    `--disable-extensions-except=${pathToExtension}`,
    `--load-extension=${pathToExtension}`
  ]
});

Uma segunda abordagem é evitar completamente os mecanismos de injeção de V8. Você pode usar um servidor proxy externo ou a interceptação de solicitações integrada do Puppeteer para modificar a resposta HTML bruta em tempo real.

Insira sua tag <script> de falsificação como a primeira linha dentro do elemento <head>. Nesse cenário, o código é executado de forma natural como parte do processo de análise de documento padrão do navegador, sem levantar suspeitas de sistemas de detecção baseados em tempo.

Se você precisar usar addScriptToEvaluateOnNewDocument, evite carregar grandes plugins furtivos monolíticos. Em vez disso, divida o processo de falsificação em duas etapas.

Antes de carregar a página, remova apenas o marcador webdriver. Este código é executado em uma fração de milissegundo e não cria anomalias detectáveis por meio da API de Desempenho (Performance API).

// Injeta uma carga útil (payload) mínima antes do início da análise de HTML
await page.evaluateOnNewDocument(() => {
    // Remove o marcador de automação mais óbvio
    Object.defineProperty(navigator, 'webdriver', {
        get: () => undefined,
    });
    // Sem falsificações pesadas de WebGL ou Canvas aqui!
});

// Injeta uma carga útil (payload) mínima antes do início da análise de HTML
await page.evaluateOnNewDocument(() => {
    // Remove o marcador de automação mais óbvio
    Object.defineProperty(navigator, 'webdriver', {
        get: () => undefined,
    });
    // Sem falsificações pesadas de WebGL ou Canvas aqui!
});

Carregue todas as outras modificações — como falsificação de GPU, áudio, plugins ou fontes — posteriormente, depois que o navegador já tiver iniciado a renderização da página. Isso pode ser feito por meio de uma chamada padrão page.evaluate() ou vinculando o processo ao evento DOMContentLoaded.

// Navega até o site
await page.goto('https://target-site.com');

// A página já está carregando e as verificações de tempo foram concluídas.
// Agora é mais seguro injetar uma lógica de falsificação mais pesada.
await page.evaluate(() => {
    // Falsifica Canvas, WebGL, fontes, etc.
    const getParameter = WebGLRenderingContext.getParameter;
    WebGLRenderingContext.prototype.getParameter = function(parameter) {
        if (parameter === 37445) return 'Intel Inc.';
        if (parameter === 37446) return 'Intel Iris OpenGL Engine';
        return getParameter(parameter);
    };
});

// Navega até o site
await page.goto('https://target-site.com');

// A página já está carregando e as verificações de tempo foram concluídas.
// Agora é mais seguro injetar uma lógica de falsificação mais pesada.
await page.evaluate(() => {
    // Falsifica Canvas, WebGL, fontes, etc.
    const getParameter = WebGLRenderingContext.getParameter;
    WebGLRenderingContext.prototype.getParameter = function(parameter) {
        if (parameter === 37445) return 'Intel Inc.';
        if (parameter === 37446) return 'Intel Iris OpenGL Engine';
        return getParameter(parameter);
    };
});

Os sistemas de proteção geralmente verificam o webdriver de forma síncrona no início do ciclo de vida da página, o que torna essa abordagem eficaz contra esse tipo de verificação. Verificações antifraude mais avançadas costumam rodar de forma assíncrona após o carregamento da página. A essa altura, o script de falsificação mais pesado da segunda fase já terá sido carregado, sem introduzir atrasos na inicialização da página.

O problema do Network.setUserAgentOverride

Alterar o User-Agent através do CDP é fácil, mas o problema é que apenas o cabeçalho HTTP é modificado dessa forma, enquanto outros indicadores ambientais permanecem intocados.

Com isso, você cria uma inconsistência crítica. O método Network.setUserAgentOverride não consegue falsificar adequadamente as propriedades internas do objeto navigator ou cabeçalhos específicos de Client Hints.

Um sistema de análise pode ver um User-Agent móvel no cabeçalho da requisição e, simultaneamente, detectar o comportamento de renderização de uma API desktop, além de cabeçalhos sec-ch-ua incompatíveis.

Nunca altere apenas a string do User-Agent. Se você estiver emulando um dispositivo, deve falsificar todo o conjunto de Client Hints, sensores de hardware e características. Em vez de depender apenas do setUserAgent, utilize os parâmetros expandidos de CDP e forneça um objeto userAgentMetadata completo. Lembre-se também de emular comportamentos específicos do aparelho, tais como emulação de tela sensível ao toque ao se passar por dispositivos móveis.

Varredura de portas TCP de depuração

Para controlar o navegador, o Puppeteer inicia o Chromium com uma porta aberta para comunicação WebSocket. Por padrão, geralmente utiliza-se uma porta de depuração local, como a clássica 9222 ou outra atribuída aleatoriamente.

Um script antifraude é executado diretamente dentro do navegador do usuário. A partir de dentro do seu próprio sistema e em nome do seu navegador, ele pode simplesmente enviar uma requisição AJAX banal como:

http://127.0.0.1:9222/json/version.

Sistemas de proteção usam os chamados ataques de temporização (timing attacks) ou varredura de rede local por meio de WebSockets. Se um script se conecta a uma porta de depuração padrão e recebe imediatamente uma resposta do motor do navegador, ele pode inferir que o navegador está sendo controlado por um script de automação.

Tornar a porta aleatória não é uma solução completa, uma vez que os scanners podem sondar faixas inteiras de portas. A solução mais simples é parar de usar portas TCP de vez para a comunicação entre o Node.js e o navegador.

O Puppeteer pode se comunicar com o Chromium por meio de pipes anônimos do sistema operacional em vez de sockets de rede. Nesse modo, nenhuma porta de depuração é aberta, não deixando nada para os sistemas antifraude varrerem.

Basta adicionar o argumento pipe: true ao iniciar o navegador. Isso protege você contra a varredura na rede host local.

Alcançando resultados sem detecção

A invisibilidade perfeita do Puppeteer é fundamentalmente impossível, porque toda forma de emulação introduz algum desvio em relação ao comportamento genuíno do usuário. Como demonstrado acima, trata-se de uma realidade meramente técnica.

Para casos de uso sérios, os plugins padrão nunca são suficientes. Alcançar um alto nível de anonimato exige uma abordagem totalmente diferente:

1. Correção de binário do Chrome (patching). Isso envolve modificar diretamente o executável do navegador, por exemplo com um editor hexadecimal. O objetivo é substituir strings de protocolo embutidas no código (hardcoded) por valores aleatórios dentro do próprio binário. Ao contrário dos plugins furtivos, que deixam uma breve janela de vulnerabilidade entre a inicialização e a injeção de JavaScript, as modificações binárias eliminam o problema em sua origem.

2. Motores de navegador especializados. Soluções a nível de arquitetura, tais como navegadores antidetecção, implementam a falsificação de impressões digitais e a ocultação de automação dentro do código-fonte C++ do motor Blink, em vez de recorrerem a injeções de JavaScript.

3. Evitar completamente o CDP. A lógica de controle pode ser movida para extensões personalizadas do Chrome que se comunicam com um servidor de controle por meio de seus próprios canais WebSocket, permitindo que você feche as portas de depuração.

Usando navegadores antidetecção

Soluções especializadas como os navegadores antidetecção merecem atenção especial. Elas resolvem o problema em questão modificando o código-fonte do Chromium, afetando o núcleo do navegador diretamente. Indicadores de automação óbvios como navigator.webdriver são, naturalmente, removidos durante a compilação do binário, em vez de serem ocultados posteriormente.

Todo o trabalho pesado envolvido na emulação de ambiente acontece nos bastidores. Quando um script de proteção solicita informações da GPU, tais como valores de fabricante ou renderizador WebGL, o motor não precisa executar um wrapper JavaScript para falsificá-los, pois o código C++ retorna os valores exigidos de forma nativa e instantânea. O mesmo se aplica a métricas mais complexas. Além disso, o usuário não interage diretamente com nenhum desses mecanismos, exceto talvez para configurar os parâmetros necessários antes de iniciar um perfil.

Do ponto de vista de um sistema antifraude, tal navegador parece pertencer a um usuário comum. Ao mesmo tempo, você pode controlar a impressão digital através do Puppeteer simplesmente conectando-o à porta aberta do navegador antidetecção.

Detalhes menos óbvios e conclusões

• Usar o argumento --disable-blink-features=AutomationControlled remove o marcador básico de webdriver, mas deixa rastros indiretos para trás.

• Forçar Log.enable e Performance.enable a permanecerem desativados reduz a telemetria disponível, mas melhora a furtividade geral.

• O novo Modo Headless (--headless=new) unifica as arquiteturas de navegadores padrão e headless, mudando a forma como ClientRects e renderização de fontes são detectadas, fazendo com que o comportamento de renderização pareça mais natural.

Contornar a detecção com sucesso não começa com a instalação de uma centena de pacotes npm. Começa com a compreensão de como o motor do navegador realmente funciona.

A automação dos navegadores modernos exige precisão ao nível de engenharia. Vazamentos de CDP não são bugs; são características arquitetônicas da tecnologia. Quanto maior for a sua compreensão do navegador, mais controle você terá sobre cada contexto de execução e mais resilientes serão seus sistemas de automação.