Blog

Você digita seu CPF num campo de consulta, aperta “buscar” e o site responde. Simples. Agora imagine que, em vez do CPF, alguém escreva naquele mesmo campo uma ordem disfarçada, e o sistema, em vez de procurar um cadastro, obedeça e entregue todos os cadastros. É isso, em essência, a injeção SQL (SQL injection): um dos ataques mais antigos da internet e, ainda assim, responsável por alguns dos maiores vazamentos de dados da história, inclusive no Brasil.

Nesta postagem você vai entender, em linguagem simples, como funciona esse ataque, por que ele ainda dá certo, que crimes são praticados durante e depois do vazamento, como a polícia investiga e, principalmente, o que cidadãos, empresas e donos de sites podem fazer para não ter seus dados levados por um campo de formulário.

1. Resumo do ataque

Quase todo site guarda informações num banco de dados e conversa com ele por meio de uma linguagem chamada SQL. Quando o site é mal programado, ele mistura o que o usuário digita (um nome, um CPF, uma senha) com as instruções que manda ao banco. O criminoso se aproveita disso: escreve no campo algo que o sistema interpreta como ordem, e não como dado. O banco obedece e pode revelar, alterar ou apagar informações. A vítima direta é a empresa ou o órgão dono do site; as vítimas indiretas são milhares ou milhões de pessoas cujos dados estavam guardados ali.

2. Conceito e objetivos

Pense num arquivo público em que você preenche uma ficha com o número do processo e o atendente vai buscá-lo. Se o atendente lê a ficha ao pé da letra e cumpre tudo o que estiver escrito, alguém pode preencher: “processo 123 e, já que está lá, traga também todos os outros”. Um atendente atento recusaria. Um sistema mal programado, não. A injeção SQL é exatamente esse “atendente obediente demais”: o defeito não está no banco de dados, mas no modo como o site repassa a ele o que o usuário digitou.

A injeção SQL pertence a uma família maior de falhas de injeção, que inclui também a injeção de comandos no sistema operacional e o Cross-Site Scripting (XSS), tema da postagem seguinte desta série. No ranking OWASP Top 10 de 2025, principal referência mundial de riscos em aplicações web, a categoria “Injeção” caiu para o 5º lugar, mas continua entre as falhas mais exploradas e mais conhecidas.

Os objetivos do criminoso:

• Roubar dados em massa: cadastros, CPFs, endereços, senhas, dados de cartão, prontuários.
• Entrar sem senha: enganar a tela de login para acessar áreas restritas ou administrativas.
• Alterar informações: mudar notas, preços, saldos, registros, ou desfigurar o site (o chamado defacement).
• Apagar dados ou sabotar o sistema.
• Ganhar um ponto de apoio para invadir o servidor e, a partir dele, a rede inteira.
• Vender ou extorquir: negociar os dados em fóruns clandestinos ou cobrar da vítima para não publicá-los.

3. Por que um ataque tão antigo ainda funciona

A injeção SQL é documentada desde o fim dos anos 1990 e as defesas são conhecidas há mais de duas décadas. Ainda assim, ela continua aparecendo em grandes incidentes. Os motivos se repetem:

• Sistemas antigos e esquecidos: páginas criadas há anos, que ninguém mais monitora, mas que continuam ligadas ao banco de dados. Foi o caso da britânica TalkTalk.
• Código feito às pressas, sem revisão de segurança, especialmente em sistemas sob encomenda de pequenas empresas e órgãos públicos.
• Plugins e extensões desatualizados em plataformas de sites e lojas virtuais.
• Ferramentas automáticas que vasculham a internet atrás de sites vulneráveis, permitindo que até adolescentes sem grande conhecimento técnico encontrem e explorem a falha.
• Produtos usados por muitas organizações: uma única injeção SQL num programa popular pode atingir milhares de vítimas, como no caso MOVEit, que contamos na postagem sobre ataques zero-day.

4. As vulnerabilidades exploradas

• Mistura de dado e instrução: o site monta a pergunta ao banco “colando” diretamente o que o usuário digitou.
• Falta de validação: o campo de CPF aceita letras e símbolos; o campo de data aceita qualquer coisa.
• Privilégios excessivos: o site conversa com o banco usando uma conta que pode ler, alterar e apagar tudo, quando só precisaria consultar uma tabela.
• Mensagens de erro detalhadas que revelam ao criminoso a estrutura interna do sistema.
• Dados sensíveis guardados sem proteção: senhas e documentos armazenados de forma legível, que tornam o vazamento muito mais grave.
• Ausência de monitoramento: tentativas de ataque passam despercebidas por semanas. A TalkTalk sofreu ataques semelhantes meses antes do grande vazamento e não reagiu.

5. Meios e modos de ataque: as fases

A descrição é conceitual, sem qualquer detalhe que permita reproduzir o ataque:

1. Varredura: programas automáticos testam milhares de sites em busca de campos de busca, login, formulários e endereços que reajam de forma suspeita.
2. Confirmação da falha: o criminoso percebe que o site responde de modo diferente a certas entradas e conclui que está “conversando” com o banco de dados.
3. Mapeamento: descobre quais tabelas e informações existem.
4. Extração (exfiltração): copia os dados, muitas vezes aos poucos, para não chamar atenção.
5. Ampliação: em alguns casos, usa a falha para instalar programas no servidor ou alterar o conteúdo do site.
6. Monetização: venda dos dados, extorsão da empresa, fraudes com os cartões ou exposição pública para ganhar fama em fóruns.

6. Gatilhos psicológicos explorados

A injeção SQL é um ataque técnico, mas se alimenta de comportamentos humanos e organizacionais:

• Do lado das organizações: o “sempre funcionou assim”, a pressa de lançar o sistema, a economia na contratação de desenvolvimento seguro e a ilusão de que “ninguém vai se interessar pelo nosso site”.
• Do lado dos autores: a busca por fama em fóruns, a sensação de impunidade e a visão do ataque como “desafio técnico”, muito comum entre jovens.
• Do lado das vítimas finais: depois do vazamento, golpistas usam os dados verdadeiros para gerar confiança (“confirme seu CPF e endereço”) e medo (“sua conta foi exposta, regularize agora”).

7. Crimes praticados e capitulação penal

Observações práticas, úteis também para quem estuda para concursos:

• O servidor do site é “dispositivo informático”. O art. 154-A protege qualquer dispositivo, conectado ou não à rede; o servidor que hospeda o site e o banco de dados está abrangido. A invasão independe de “quebrar” uma senha: explorar uma falha para acessar sem autorização já configura o tipo.
• Desfigurar o site também é crime. Adulterar dados do sistema, inclusive a página inicial, enquadra-se no caput do art. 154-A.
• Quem compra a base de dados sabendo da origem criminosa pode responder por receptação de dados? A questão é controvertida, porque dados não são “coisa” no sentido tradicional do art. 180 do CP. Por isso, o mais comum é a responsabilização pelos crimes praticados com os dados (fraudes) ou pela participação na difusão (art. 154-A, § 4º, combinado com o art. 29 do CP).
• Ação penal. A invasão depende de representação, salvo contra a administração pública ou concessionárias (art. 154-B). Extorsão e furto mediante fraude são de ação pública incondicionada.
• Adolescentes. Muitos autores são jovens. Abaixo de 18 anos, a conduta é ato infracional, nos termos do ECA, e os pais podem responder civilmente pelos danos.

E a responsabilidade de quem foi invadido? A LGPD (Lei 13.709/2018) exige medidas de segurança aptas a proteger os dados pessoais (art. 46), a comunicação de incidentes relevantes à ANPD e aos titulares (art. 48), no prazo de três dias úteis previsto na Resolução CD/ANPD nº 15/2024, e permite sanções administrativas (art. 52). Deixar uma falha conhecida e de correção simples aberta por anos pesa contra a empresa, como mostrou a multa aplicada à TalkTalk pela autoridade britânica de proteção de dados.

8. O efeito cascata: os crimes que vêm depois

O vazamento acontece uma vez; o uso dos dados dura anos:

1. Golpes com dados verdadeiros: falsas centrais, boletos falsos e falsos atendentes que citam CPF, endereço e número de contrato para parecer legítimos.
2. Teste de senhas em outros serviços (credential stuffing), quando as senhas vazam legíveis ou são decifradas.
3. Fraudes com cartões e compras em nome das vítimas.
4. Abertura de contas, empréstimos e cadastros falsos com documentos vazados.
5. Alimentação dos “painéis de consulta” clandestinos, que vendem a qualquer interessado CPF, endereço, telefone e parentes de milhões de brasileiros, abastecendo golpistas, perseguidores e criminosos violentos.
6. Extorsão da empresa e, depois, das pessoas cujos dados eram sensíveis.
7. Infecção do próprio site, que passa a distribuir programas maliciosos ou páginas falsas aos visitantes (veja o guia de malware), e porta de entrada para o ransomware.

Os crimes de amanhã. Três tendências merecem atenção: (1) ferramentas de inteligência artificial que varrem milhões de sites e adaptam o ataque automaticamente; (2) a “injeção de comandos” em assistentes de inteligência artificial (prompt injection), herdeira direta da injeção SQL, em que instruções escondidas em textos, e-mails ou páginas fazem o assistente revelar dados ou executar ações indevidas; e (3) a integração cada vez maior entre sistemas públicos e privados, em que uma única porta mal protegida dá acesso a bases gigantescas.

9. Casos reais

Heartland e Albert Gonzalez: 130 milhões de cartões (2008–2010)

Em agosto de 2009, a Justiça americana acusou Albert Gonzalez, de Miami, pelo que era então o maior roubo de dados de cartões já processado nos Estados Unidos: mais de 130 milhões de números de cartões de crédito e débito, obtidos de redes como a processadora Heartland Payment Systems e as redes 7-Eleven e Hannaford. Segundo a acusação, o grupo usou injeção SQL para ganhar o primeiro acesso e, a partir daí, instalou programas que capturavam os dados das transações. Em março de 2010, Gonzalez foi condenado a 20 anos de prisão. A Heartland estimou seus prejuízos em cerca de US$ 130 milhões.

TalkTalk: uma página esquecida e adolescentes com ferramenta automática (2015–2018)

Em outubro de 2015, a operadora britânica TalkTalk teve dados de cerca de 157 mil clientes expostos, mais de 15 mil deles com dados bancários. O ataque explorou injeção SQL em páginas antigas, herdadas de outra empresa e esquecidas, ligadas a um banco de dados sem uma correção disponível desde 2012. A autoridade britânica de proteção de dados (ICO) concluiu que o ataque poderia ter sido evitado com medidas básicas, registrou que houve ataques semelhantes meses antes e aplicou multa recorde à época de £400 mil. Os autores eram em grande parte jovens: um adolescente de 17 anos foi condenado a medida de reabilitação e, em 2018, dois jovens adultos foram presos. A empresa estimou o custo total do incidente em £77 milhões.

TSE: o vazamento no dia da eleição (2020)

No primeiro turno das eleições municipais de 2020, um grupo luso-brasileiro divulgou dados de servidores e ex-servidores do Tribunal Superior Eleitoral. Segundo reportagem do site O Bastidor, citada pelo Baguete, os invasores acessaram bancos de dados do tribunal usando uma ferramenta automatizada de injeção SQL. O TSE informou que os dados eram antigos e que não houve qualquer impacto na votação. Em operação conjunta da Polícia Federal com a polícia portuguesa, um jovem de 19 anos apontado como líder do grupo foi preso em Portugal, e foram cumpridos mandados de busca no Brasil. O caso mostra que órgãos públicos de primeiro escalão também mantêm sistemas antigos expostos.

10. Casos ilustrativos (fictícios)

Os casos abaixo foram criados para fins didáticos. Qualquer semelhança com pessoas, empresas ou fatos reais é coincidência.

Caso 1 – A loja virtual de bairro. Uma pequena loja de suplementos usa um plugin de catálogo desatualizado há dois anos. Um grupo encontra a falha numa varredura automática e copia o cadastro de 40 mil clientes. Semanas depois, os clientes começam a receber ligações de uma “central da loja” oferecendo reembolso e pedindo um Pix de “taxa de liberação”. Enquadramento possível: art. 154-A, §§ 3º e 4º; fraude eletrônica (art. 171, § 2º-A) contra cada cliente enganado. Para a loja, dever de comunicar o incidente à ANPD e aos titulares.

Caso 2 – O portal de licitações. Um criminoso explora uma injeção SQL no portal de licitações de uma prefeitura, obtém os dados cadastrais de servidores e fornecedores e os vende a um painel clandestino de consultas. Enquadramento possível: art. 154-A, §§ 3º e 4º (ação penal pública incondicionada, por atingir a administração pública); organização criminosa e lavagem, se comprovada a estrutura do painel.

Caso 3 – As notas da escola. Um aluno de 16 anos assiste a um vídeo, baixa uma ferramenta automática e a usa contra o sistema acadêmico da escola, alterando as próprias notas e as de colegas. Enquadramento possível: ato infracional análogo ao art. 154-A (adulteração de dados), apurado pelo ECA, com possível responsabilidade civil dos pais. Para a escola, revisão urgente do sistema e comunicação aos responsáveis pelos dados.

Caso 4 – O cenário de amanhã. O assistente de inteligência artificial de uma empresa de planos de saúde lê os e-mails dos clientes para agilizar o atendimento. Um criminoso envia um e-mail com instruções escondidas no texto; o assistente as interpreta como ordens e responde com dados de outros pacientes. É a velha lógica da injeção (dado tratado como ordem) aplicada à inteligência artificial, e o enquadramento continua a passar pelo art. 154-A e pela LGPD.

11. Sinais de alerta (checklist)

Para quem tem ou administra um site

• Mensagens de erro do banco de dados aparecendo para os visitantes.
• Registros com grande volume de acessos estranhos a páginas de busca, login ou formulários.
• Usuários administradores que ninguém criou; conteúdo alterado; páginas novas que ninguém publicou.
• Banco de dados lento ou volume incomum de dados saindo do servidor.
• Avisos do provedor de hospedagem, do CERT.br ou de pesquisadores sobre falha no site.
• Dados dos seus clientes anunciados em fóruns ou sendo usados em golpes.

Para o cidadão

• Ligações e mensagens de golpistas que sabem demais sobre você.
• Avisos de empresas sobre incidente de segurança envolvendo seus dados.
• Tentativas de login ou de troca de senha que você não fez.

12. Prevenção

Para empresas, órgãos públicos e donos de sites

• Separe dado de instrução: exija dos desenvolvedores o uso de consultas parametrizadas, a defesa padrão recomendada pela OWASP, em que o que o usuário digita nunca é tratado como ordem.
• Valide as entradas: campo de CPF aceita números; campo de data aceita datas.
• Privilégio mínimo no banco: o site deve usar uma conta que só faça o estritamente necessário.
• Atualize a plataforma, os temas e os plugins e remova os que não usa. Em sites WordPress, plugins desatualizados estão entre as portas mais comuns.
• Faça inventário: desative páginas e sistemas antigos esquecidos.
• Esconda os detalhes técnicos das mensagens de erro exibidas ao público.
• Proteja os dados guardados: senhas com algoritmos próprios para isso e dados sensíveis criptografados, para que um eventual vazamento tenha menor impacto.
• Use firewall de aplicação web como camada adicional, sem substituir o código seguro.
• Contrate testes de invasão autorizados e mantenha um canal para pesquisadores reportarem falhas.
• Monitore e guarde registros; tenha um plano de resposta a incidentes com contatos da polícia, do CERT.br e da ANPD.
• Colete menos dados: o que não está guardado não pode vazar.

Para o cidadão

• Use senhas diferentes para cada serviço e um gerenciador de senhas: o vazamento de um site não abre os demais.
• Ative a verificação em duas etapas, de preferência com aplicativo ou chave de acesso.
• Use cartão virtual para compras online, sobretudo em lojas pequenas.
• Forneça apenas os dados necessários em cadastros.
• Desconfie de quem sabe demais: ter seus dados não prova que a ligação é do banco ou da loja. Desligue e ligue você mesmo para o número oficial.

13. Já fui vítima: o que fazer

Se o seu site ou sistema foi invadido

1. Contenha: tire do ar a página vulnerável ou coloque o site em manutenção, sem apagar nada.
2. Preserve as provas: registros do servidor, da aplicação e do banco de dados, cópias do estado do sistema e mensagens de extorsão.
3. Corrija a falha e verifique se o invasor deixou contas, arquivos ou portas dos fundos.
4. Troque todas as senhas de administração, do banco de dados e da hospedagem.
5. Registre boletim de ocorrência, de preferência em delegacia especializada em crimes cibernéticos, e notifique o CERT.br.
6. Avalie a comunicação à ANPD e aos titulares (art. 48 da LGPD), no prazo de três dias úteis, e oriente seus clientes sobre golpes que podem usar os dados.
7. Não negocie com extorsionários sem orientação jurídica e policial.

Se os seus dados vazaram

1. Troque a senha daquele serviço e de todos em que você usava a mesma senha.
2. Ative a verificação em duas etapas.
3. Se havia cartão cadastrado, avise o banco e peça a substituição.
4. Consulte o Registrato, do Banco Central, para checar contas e empréstimos em seu nome.
5. Redobre a atenção a ligações e mensagens que usem seus dados e, se cair em golpe com Pix, peça imediatamente ao banco o MED (Mecanismo Especial de Devolução).
6. Se a empresa não informar ou não resolver, registre reclamação na ANPD e no consumidor.gov.br; se sofrer prejuízo, registre boletim de ocorrência.

14. Públicos mais vulneráveis e cuidados específicos

• Pequenas lojas virtuais e prestadores de serviço com sites feitos sob encomenda e sem manutenção.
• Prefeituras, câmaras e órgãos públicos com sistemas antigos e terceirizados.
• Escolas, faculdades, clínicas e associações, que guardam dados sensíveis em sistemas simples.
• Blogs e sites institucionais com plugins abandonados.
• Idosos, alvos preferenciais dos golpes que usam dados vazados para parecer legítimos.

15. Repressão: como a polícia investiga

• Registros do servidor e da aplicação: revelam os pedidos maliciosos, os horários e os endereços de origem. Sem registros guardados, a investigação começa às cegas.
• Requisição de dados aos provedores: o Marco Civil da Internet (Lei 12.965/2014) obriga a guarda de registros por 1 ano (provedores de conexão, art. 13) e por 6 meses (provedores de aplicação, art. 15), acessíveis por ordem judicial (art. 22).
• Monitoramento de fóruns e mercados clandestinos: a venda ou a exibição pública da base de dados deixa rastros de apelidos, contas e carteiras de criptoativos.
• Perícia e cadeia de custódia (arts. 158-A a 158-F do CPP) nos servidores atacados e nos equipamentos apreendidos.
• Cooperação internacional: como no caso TSE, autores e servidores podem estar em outros países; a Convenção de Budapeste, promulgada pelo Decreto 11.491/2023, facilita a obtenção de provas.
• Atuação conjunta com a ANPD, que apura a responsabilidade administrativa de quem guardava os dados.

16. Guia de leitura: as falhas de sites no blog

• A injeção SQL que virou zero-day: Ataque Zero-Day: a falha que nem o fabricante conhece (caso MOVEit).
• Outra falha que derrubou sites: PHP2Shell: a falha que fez governos e empresas tirarem sites do ar.
• O destino das senhas vazadas: Credential Stuffing: a senha que vazou em um site abre as suas outras contas.
• O ataque que pode vir depois: Ransomware: o sequestro de dados que paralisa empresas, hospitais e tribunais.

Fontes

• OWASP Top Ten 2025 – The Complete Guide – Reflectiz, janeiro de 2026.
• OWASP Top 10 2025 Released: Our Insights and Contribution – usd AG, 14/11/2025.
• Hacker faces 20 years in prison for attack on U.S. retail and banking networks – Help Net Security, agosto de 2009.
• Federal judge hands down 20-year sentence in largest identity theft case in US history – JURIST, março de 2010.
• Albert Gonzalez, Mastermind Heartland Hacker, Gets 20 Years – Credit Union Times, 06/04/2010.
• TalkTalk fined record £400,000 over data breach – The Hacker News, outubro de 2016.
• Two Friends Who Hacked TalkTalk Receive Prison Sentences – GovInfoSecurity, novembro de 2018.
• Two Brits jailed over TalkTalk hack – WeLiveSecurity/ESET, 21/11/2018.
• Hacker preso por ataque ao TSE – Baguete, 30/11/2020.
• Hacker de 19 anos é preso em Portugal por ataque ao TSE – Tecnoblog, novembro de 2020.
• Cartilha de Segurança para Internet – CERT.br/NIC.br.
• Código Penal e Lei 14.155/2021 – Planalto.
• LGPD (Lei 13.709/2018) e Marco Civil da Internet (Lei 12.965/2014) – Planalto.

Leia também

• Ataque XSS (Cross-Site Scripting): quando um site verdadeiro vira armadilha para quem o visita
• Ataque Zero-Day: a falha que nem o fabricante conhece
• Credential Stuffing: a senha que vazou em um site abre as suas outras contas
• PHP2Shell: a falha que fez governos e empresas tirarem sites do ar
• Ransomware: o sequestro de dados que paralisa empresas, hospitais e tribunais
• Malware: o guia completo dos programas maliciosos
• Convenção de Budapeste: o tratado que mudou a investigação de crimes cibernéticos no Brasil

Chamada para Mentoria

O servidor de um site é “dispositivo informático”? Desfigurar uma página configura invasão? Quem compra uma base de dados vazada comete receptação? Funcionário público que altera o sistema responde pelo art. 313-A ou pelo 313-B? Esses pontos aparecem com frequência nas provas objetivas, discursivas e orais para Delegado de Polícia, ao lado de LGPD e prova digital.

Se você quer se preparar com quem vive a investigação desses crimes na prática, conheça a Mentoria para Delegado de Polícia e estude com método, estratégia e acompanhamento individual.

Sobre o Autor

Ronaldo Entringe é Delegado de Polícia Civil do Estado do Amapá e Delegado-Chefe da Divisão Especial de Combate à Corrupção (DECOR/PCAP), com 15 anos de experiência policial. Professor de Medicina Legal e escritor, é mestrando em Ciberdelincuencia pela Universitat Oberta de Catalunya (UOC) e pós-graduando em Crimes Cibernéticos, Cibersegurança e Inteligência pelo Instituto Rogério Greco. Atua como mentor de carreiras policiais e de futuros Delegados de Polícia.