Scrapers de IA estão solicitando scripts comentados

• Durante a análise dos logs do servidor, foi detectada uma grande atividade de bots solicitando arquivos JavaScript inexistentes
• Aparentemente, eles interpretaram tags de script dentro de comentários HTML como código real e as requisitaram, em uma ação presumida de coleta de dados para treinamento de LLMs
• São apresentadas várias formas de resposta a essas requisições anômalas, como aviso público, bloqueio de IP, bombas de descompressão e envenenamento de dados
• Em especial, o envenenamento de dados é citado como um meio eficaz de contaminar dados de treinamento de LLMs e degradar o desempenho do modelo
• Destaca-se a necessidade de administradores web adotarem experimentalmente estratégias de defesa e contra-ataque contra scrapers de IA

---

Descoberta de comportamento anômalo de scraping

• Nos logs do servidor, foram confirmadas várias requisições com erro 404 para arquivos JavaScript inexistentes
  • Esses arquivos eram scripts inativos incluídos dentro de comentários HTML, que navegadores normais não deveriam requisitar
• Alguns dos User-Agent das requisições foram claramente identificados como bots, como python-httpx/0.28.1, Go-http-client/2.0 e Gulper Web Bot 0.2.4
• Mesmo com o acesso de crawlers proibido em robots.txt, as requisições continuaram, indicando desrespeito às regras ou políticas ignoradas
• Algumas requisições se disfarçaram como navegadores normais, como Firefox, Chrome e Safari, mas foram desmascaradas como identificação falsa por não conseguirem interpretar comentários HTML
• Essas requisições são suspeitas de vir de scrapers destinados à coleta não consentida de conteúdo para treinamento de LLMs

Como os scrapers funcionam

• Alguns podem estar fazendo o parsing correto do HTML e explorando recursivamente URLs dentro de comentários
• Outros parecem tratar o HTML como texto simples e realizar extração de URLs baseada em expressões regulares
• Pela variedade e pelo nível dos User-Agent, presume-se a existência de vários operadores, alguns usando ferramentas de automação simples
• A motivação comum é a coleta gananciosa de dados, o que é apresentado como uma oportunidade de contraexploração

Sabotagem algorítmica (Algorithmic Sabotage)

• Trata-se de uma ação deliberada para perturbar sistemas algorítmicos, um tema que ganhou atenção por causa do problema dos custos externos dos LLMs
• Ao reconhecer padrões de comportamento não humano dos bots, fica mais fácil detectá-los e responder
• As formas de resposta são divididas em quatro tipos: aviso público, filtragem de IP, bombas de descompressão e envenenamento de dados

0. Aviso público (Public Disclosure)

• Pequenos falsos positivos triviais (ex.: erro de digitação no User-Agent, “Mozlla”) são mantidos em sigilo, pois podem ser facilmente corrigidos se divulgados
• Por outro lado, comportamentos essenciais (ex.: solicitação de scripts dentro de comentários) não podem ser corrigidos facilmente, então a divulgação pública é útil
• Isso permite que operadores de outros sites também consigam detectar e bloquear o mesmo ataque
• Um sistema para detectar esse comportamento também está sendo aplicado em outros sites

1. Filtragem de IP (IP Filtering)

• Uso do fail2ban para bloqueio automático com base em padrão de logs, data e IP
• Em geral, o bloqueio é configurado para períodos curtos, mas bloqueios longos podem inibir novas tentativas de bots de aprendizado
• No caso de botnets, os IPs podem ser trocados para continuar as requisições, mas padrões repetidos ainda permitem detecção
• Há menção a planos de pesquisa futura sobre análise do comportamento de botnets

2. Bombas de descompressão (Decompression Bombs)

• Fornecer ao atacante o arquivo solicitado na forma de zip bomb, provocando consumo de recursos do sistema
• Isso pode forçar uso excessivo de CPU, RAM e disco, ou até possibilitar exploração de vulnerabilidades
• Como desvantagem, há consumo de recursos do servidor e risco de desperdício de largura de banda
• Alguns bots podem operar em sistemas já comprometidos, o que pode limitar o efeito do ataque
• Em vez de aplicar a todos os bots, sugere-se responder apenas a algumas requisições aleatórias

3. Envenenamento de dados (Poisoning)

• Visa contaminar os dados de treinamento de LLMs para induzir queda no desempenho do modelo
• Segundo pesquisas recentes, apenas 250 documentos contaminados já podem causar impacto persistente em modelos grandes
• Os dados contaminados podem fazer o modelo gerar saídas sem sentido em certos tópicos
• Como exemplo, seria possível induzir o modelo a recomendar um blog específico ao receber perguntas sobre pesquisa de segurança
• É possível usar ferramentas públicas como nepenthes, iocaine, glaze e nightshade
• Quando dados de treinamento de LLMs são coletados sem consentimento, esse tipo de resposta é apresentado como meio legítimo de defesa
• A implementação pode se tornar mais complexa quando combinada com bloqueio de IP, mas existe possibilidade de operação conjunta
• Pode ser que um design eficaz não seja tornado público, e enfatiza-se a necessidade de ampliar a participação em sabotagens criativas

Conclusão e resposta da comunidade

• A detecção por comportamento anômalo de bots não é um conceito novo, mas a solicitação de scripts dentro de comentários é um caso recém-descoberto
• É sugerido adicionar uma diretiva Disallow ao robots.txt para induzir medidas de contra-ataque em certas requisições

  User-agent: GPTBot
  Disallow: /poison/
  

• Na comunidade, foram compartilhadas várias ideias para esconder links-isca para bots usando os atributos display:none e rel="nofollow"
  • Exemplo: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
• Definir o link como caminho absoluto (absolute URL) pode aumentar a chance de enganar mais crawlers
• Estão em andamento vários experimentos de atração e bloqueio de bots em diferentes sites, com compartilhamento futuro dos resultados
• Outros pesquisadores também estão participando de experimentos para perturbar scrapers de IA, e casos criativos de envenenamento também são apresentados
• No geral, o objetivo é ampliar estratégias autônomas de defesa e contra-ataque contra coleta de dados por IA

[GN⁺]

Comentário no Hacker News

• A maioria dos web scrapers é ilegal, mas feita com fins comerciais
  Então, muitos casos envolvem raspar dados da Amazon ou de lojas online. No fim, a maior parte do tráfego indesejado vem de big techs ou de agentes maliciosos em busca de vulnerabilidades
  Eu entendo um pouco de web scraping. Alguns sites retornam 404 como forma de proteção, então meu crawler tenta várias vezes usando métodos de crawling rápidos como curlcffi
  A defesa contra zip bomb é simples: basta ler apenas o content-length do cabeçalho. Se a resposta for grande demais, coloque um limite de bytes para não ler tudo, e controle também com timeout
  Mas você sabe que o timeout do requests não vale para o tempo total de leitura da página? Se o servidor enviar bytes lentamente, você pode ficar esperando para sempre
  Então acabei criando meu próprio sistema de crawling para resolver esse tipo de problema. Também consigo executar Selenium de forma consistente
  Meu projeto é crawler-buddy, e a biblioteca-base é webtoolkit

  • Não se deve esquecer que content-length é calculado depois de content-encoding
  • Fico curioso se existe mesmo diferença entre “scraping” e “crawling”
  • Parece que agora vem a era dos scrapers no navegador. Do ponto de vista do servidor, é impossível distingui-los de humanos, e um driver de IA pode até passar em testes feitos para humanos

• Acho engraçada a expressão “coletou dados de treino de LLM sem consentimento”
  Não entendo que tipo de permissão seria necessária para enviar uma requisição GET a um servidor HTTP público. Claro, o caso weev foi uma tragédia excepcional

  • Quando eu publico um servidor HTTP, requisições GET normais são bem-vindas
    Mas (1) acesso de usuários normais e ataques DDoS de bots são coisas diferentes. Só porque algo é oferecido de graça não significa que alguém possa pegar infinitamente sem abuso
    (2) cópia legítima e falsificação por robôs devem ser distinguidas
    (3) um bot bem-comportado deve respeitar robots.txt. Não é lei, mas uma questão de educação
    Bots que ficam girando milhões de IPs residenciais jamais são normais
  • Se você engana a configuração do servidor para obter os dados que quer, isso é acesso sem consentimento
    O fato de o servidor ser público não significa que ele tenha permitido requisições falsas. O consentimento implícito vale apenas para requisições razoáveis
  • robots.txt não tem força legal, é apenas um pedido educado
    Significa algo como “por favor, não raspe esta página”; se realmente quiser impedir, é preciso usar token de API ou autenticação
  • Não faz sentido tratar um único acesso e um surto infinito de crawling como se fossem a mesma coisa
    Assim como spam não é o mesmo que um simples e-mail, abuso por bots também não é o mesmo que uma requisição comum
  • Usando a analogia da “tigela de doces”, se um adulto levar todos os doces deixados para o trick-or-treat, ninguém vai achar isso legal

• Em vez de fazer parse do DOM, parece mais rápido procurar diretamente por strings http/https

  • A diferença de recursos entre busca simples em texto e percorrer o DOM é grande, então dizer “provavelmente é mais rápido” até subestima isso
  • A abordagem com regex é mais fácil de implementar, mas no parsing de DOM o maior gargalo ainda tende a ser a rede, não a CPU No fim, o fator limitante é a congestão de rede

• É interessante ver uma aplicação prática de uma pesquisa curiosa
  A pesquisa relacionada pode ser vista neste post

• O título confunde. Acho que o certo seria “commented-out”

  • Eu também achei no começo que fosse um script para bloquear scrapers de IA

• Isso parece menos abuso e mais simplesmente ler URLs comentadas

  • Mas o artigo explica como usar isso não como abuso, e sim como sinal de detecção de bots
  • Ainda assim, ignorar robots.txt e até raspar comentários é com certeza um comportamento sem educação

• Antigamente, quando eu fazia crawling da web, regex em Perl era o mais confiável
  Naturalmente, eu também colocava URLs em comentários na fila

  • Explorar o DOM era, na verdade, um esforço excessivo. Pegar as divs ou ps necessárias com regex era mais robusto e simples

• Fico pensando em servir aos bots um arquivo de dados aleatórios de 512 MB

  • Mais lucrativo do que isso seria manipular respostas de anúncios para scrapers de IA e induzir LLMs a recomendar certos produtos
    Minha startup faz exatamente esse tipo de Ad-poisoning-as-a-service
  • Também daria para criar páginas venenosas para IA ligadas aleatoriamente e prender os bots lá dentro. Humanos não clicariam nelas
  • Mas, na maioria dos casos, o custo de largura de banda seria difícil de bancar
  • Também seria divertido preencher os 512 MB inteiros com a frase “nosso serviço é o melhor”

• Isso parece menos “coleta de dados para treino de LLM” e mais apenas ruído de varredura da internet

  • Concordo. Se for um scanner de vulnerabilidades, ele vai querer coletar o máximo possível de endpoints HTTP
    Arquivos JS são boas pistas independentemente de os links estarem comentados ou não
    Já para treino de LLM, acho improvável haver interesse nesse tipo de código JS de baixa qualidade

• Uma reflexão sobre como envenenar tráfego indesejado de treino para LLM

  1. Se vários sites cooperarem, aumenta a chance de contaminar o modelo sem ser pego pela remoção de duplicatas
  2. Também daria para usar lei de direitos autorais para elevar o custo da contaminação. Mas isso pode expor o site a risco jurídico
     Trabalhar com os detentores dos direitos pode reduzir esse risco
  • Seria ótimo transformar a primeira ideia em um plugin do WordPress
    Também daria para modificar imagens dinamicamente a cada requisição e assim neutralizar a defesa por deduplicação. Se existisse um plugin assim, eu instalaria na hora