12 de Outubro: Como o Nerd Cult Lidou com uma Tentativa de SQL Injection

No dia 12 de outubro, vi um número de acessos ao Nerd Cult que, à primeira vista, parecia uma ótima notícia: mais de mil tentativas em poucas horas. O primeiro pensamento foi que o conteúdo finalmente estava chegando a mais leitores.

A análise dos registros mudou essa impressão. Em vez de navegação normal, encontrei requisições concentradas em pontos que recebem texto, como o formulário de contato e os comentários. Parte dos valores enviados continha sequências que pareciam tentar manipular consultas SQL.

Os registros mostravam automação e tentativas compatíveis com SQL Injection. Isso, por si só, não comprova que os pedidos vieram de um botnet específico; para afirmar isso seria necessário reunir evidências adicionais sobre a origem e a infraestrutura por trás das requisições.

O incidente serviu como um teste inesperado para decisões que eu já havia tomado no desenvolvimento do blog. O banco permaneceu intacto, mas os formulários e as notificações foram atingidos pelo volume de mensagens automatizadas. Neste relato, separo o que observei das conclusões técnicas e mostro as medidas que ajudam a reduzir esse tipo de risco.

O padrão era diferente do comportamento de um leitor preenchendo um formulário. As requisições chegavam em sequência, com valores repetitivos e conteúdo que não fazia sentido como comentário ou mensagem de contato.

Os pontos atingidos incluíam:

• Campos de texto do formulário de contato;
• Campos de nome ou autor dos comentários;
• Outros campos públicos que aceitam texto enviado pelo visitante.

Entre os valores registrados havia tentativas compatíveis com Time-Based Blind SQL Injection. Nessa técnica, o atacante tenta provocar uma demora controlada no banco e observa o tempo de resposta. Uma diferença consistente pode ajudar a inferir se uma expressão SQL foi processada, mas um atraso isolado não prova que a injeção funcionou: latência de rede, carga do servidor e outros fatores também influenciam a resposta. A OWASP explica essa família de ataques em sua documentação sobre Blind SQL Injection.

Exemplos representativos que apareceram nos registros:

• WAITFOR DELAY, uma construção associada a tentativas de atraso no SQL Server;
• SLEEP(), função usada em payloads direcionados a MySQL/MariaDB;
• Expressões booleanas artificiais, usadas para observar diferenças na resposta da aplicação.

Os formatos variavam, algo comum em ferramentas automatizadas que testam várias tecnologias. O intervalo curto entre requisições reforçou a hipótese de automação, mas não permite identificar sozinho quem estava por trás dela.

A questão mais importante deixou de ser o número de requisições e passou a ser esta: o conteúdo enviado pelos formulários conseguia alterar a estrutura das consultas ao banco?

No Nerd Cult, as consultas comuns ao banco são construídas com Entity Framework Core e LINQ. Nesse caminho, o EF Core normalmente transforma a expressão em SQL parametrizado, enviando os valores do usuário como parâmetros em vez de concatená-los à instrução SQL. Essa separação é uma das principais defesas contra SQL Injection.

Por exemplo, uma consulta como esta:

var comentarios = await context.Comments
    .Where(c => c.AuthorName == nomeInformado)
    .ToListAsync();

não precisa montar uma string SQL com o conteúdo de nomeInformado. O provedor do EF Core gera a consulta e transmite o valor como parâmetro. Assim, uma entrada que contenha caracteres usados em SQL continua sendo tratada como valor, e não como parte executável da consulta.

Isso não significa que o Entity Framework Core torne qualquer código automaticamente seguro. O risco reaparece se a aplicação montar SQL dinâmico por concatenação, usar APIs de SQL bruto de forma insegura ou construir nomes de colunas e trechos da consulta diretamente com entrada do usuário. A documentação da Microsoft explica os cuidados necessários em consultas SQL no EF Core, e a OWASP mantém um guia prático de prevenção de SQL Injection.

No meu caso, a estrutura de acesso a dados que já utilizava foi uma parte importante da defesa. Ao revisar o incidente, não encontrei evidência de alteração ou vazamento do banco decorrente dessas tentativas. Essa conclusão se refere ao que consegui verificar nos registros e no estado da aplicação; não significa que uma tecnologia, sozinha, ofereça garantia absoluta contra qualquer ataque.

A lição é simples: usar LINQ e consultas parametrizadas reduz muito o risco, mas ainda é necessário revisar cada ponto em que a aplicação conversa com o banco, especialmente quando existe SQL escrito manualmente.

Mesmo sem evidência de comprometimento do banco, o ataque gerou trabalho. Os formulários públicos receberam conteúdo automatizado e parte das mensagens precisou ser revisada ou removida.

• Comentários com sequências que não tinham relação com o assunto das publicações;
• Mensagens indevidas no formulário de contato;
• Notificações por e-mail geradas por envios automatizados;
• Tempo gasto para identificar os registros, limpar o conteúdo e verificar a aplicação.

Isso é importante porque segurança não se resume a impedir que uma consulta maliciosa altere o banco. Um formulário pode continuar sendo abusado para gerar spam, consumir recursos, acionar notificações e sobrecarregar a moderação, mesmo quando as consultas estão parametrizadas.

Depois do incidente, reforcei as medidas voltadas a reduzir o ruído dos formulários e limitar envios em sequência. Elas complementam a proteção contra SQL Injection; não substituem consultas parametrizadas, validação de entrada nem uma revisão de segurança.

Camada 1: validação e filtro de conteúdo abusivo

Os campos passaram a ser tratados também como uma superfície de spam. A aplicação valida tamanho, formato e campos obrigatórios e pode aplicar regras antispam para padrões claramente abusivos antes de salvar a mensagem ou enviar notificações.

É importante não confundir esse filtro com uma defesa de SQL Injection. Criar uma lista negra baseada em palavras como select, union ou drop pode bloquear mensagens legítimas e ainda deixar passar payloads escritos de outra forma. A proteção principal continua sendo parametrizar as consultas. O filtro deve servir para reduzir abuso e ruído, não para decidir se um valor pode ser concatenado ao SQL.

Camada 2: Rate Limiting no ASP.NET Core

O ASP.NET Core oferece middleware de Rate Limiting para limitar a frequência com que uma política aceita requisições. O recurso está disponível a partir do ASP.NET Core 7 e pode ajudar a conter rajadas de envios em comentários e formulários. Veja a documentação oficial de Rate Limiting.

A política precisa ser aplicada especificamente aos endpoints que recebem os envios. O exemplo abaixo limita cada endereço IP a três requisições em uma janela de 30 segundos. É uma configuração ilustrativa: os limites devem ser ajustados ao comportamento legítimo do site, e o IP pode não representar uma única pessoa, especialmente em redes compartilhadas.

using System.Threading.RateLimiting;

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddPolicy("formularios", httpContext =>
        RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: httpContext.Connection.RemoteIpAddress?.ToString()
                ?? "ip-desconhecido",
            factory: _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = 3,
                Window = TimeSpan.FromSeconds(30),
                QueueLimit = 0,
                AutoReplenishment = true
            }));
});

var app = builder.Build();

app.UseRouting();
app.UseRateLimiter();

// Aplique a política "formularios" apenas às rotas
// de comentário e contato, por exemplo com RequireRateLimiting
// no endpoint ou EnableRateLimiting no controller.
app.MapControllers();

app.Run();

Para que a política realmente proteja os formulários, associe-a às rotas correspondentes usando RequireRateLimiting("formularios") ou o atributo [EnableRateLimiting("formularios")]. Apenas registrar o serviço e chamar UseRateLimiter() não aplica automaticamente essa política a todos os endpoints.

Também é importante configurar corretamente os cabeçalhos encaminhados quando a aplicação está atrás de um proxy ou balanceador. Não confie cegamente em um cabeçalho de IP enviado pelo próprio cliente. Em aplicações com várias instâncias, um limitador em memória por processo pode não representar um limite global; nesse cenário, avalie controles no proxy, gateway ou infraestrutura.

Quando a política é atingida, a aplicação pode responder com HTTP 429 Too Many Requests e uma mensagem curta orientando o visitante a aguardar. O Rate Limiting reduz abuso e carga, mas não corrige uma consulta SQL vulnerável.

O episódio reforçou uma ideia que vale para qualquer projeto: segurança não é um recurso que se instala no fim do desenvolvimento. Ela depende de decisões consistentes ao longo de toda a aplicação.

Estas são as verificações que considero prioritárias:

• Use consultas parametrizadas: evite concatenar dados recebidos do usuário em strings SQL;
• Revise SQL bruto: verifique usos de FromSqlRaw, ExecuteSqlRaw e outras APIs de SQL manual, garantindo que os parâmetros sejam utilizados corretamente;
• Valide no servidor: limite tamanho, formato e tipo dos dados conforme a finalidade de cada campo;
• Use menor privilégio: a conta da aplicação no banco não deve ter permissões além das necessárias;
• Proteja os formulários: aplique Rate Limiting, antispam e controles adequados ao risco;
• Registre eventos úteis: mantenha logs que permitam identificar padrões sem armazenar senhas, tokens ou outros dados sensíveis;
• Tenha um plano de resposta: revise logs, verifique integridade, atualize dependências e saiba como suspender temporariamente um endpoint abusado.

A OWASP mantém recomendações detalhadas sobre prevenção de SQL Injection e validação de entrada. Vale consultar essas referências ao revisar uma aplicação real.

Nenhuma dessas medidas garante invulnerabilidade. A combinação de consultas seguras, permissões restritas, monitoramento e limites de requisição, porém, reduz riscos diferentes e torna os incidentes mais fáceis de investigar.

Em 12 de outubro de 2026, o Nerd Cult recebeu uma onda de requisições que parecia tráfego à primeira vista, mas os registros revelaram tentativas automatizadas com indícios de SQL Injection. O banco permaneceu intacto segundo as verificações que realizei, enquanto os formulários e as notificações exigiram trabalho de limpeza.

Para mim, a principal lição não é que o Entity Framework Core resolve toda questão de segurança. É que usar LINQ e consultas parametrizadas como padrão evita uma classe importante de erros, desde que a aplicação não contorne essa proteção com SQL dinâmico inseguro. As camadas adicionais, como Rate Limiting e antispam, ajudam a lidar com o abuso que ainda pode acontecer.

Se você mantém uma aplicação web, reserve um tempo para revisar o acesso ao banco, as permissões da conta de serviço e os endpoints públicos. Segurança não é uma promessa de que nada acontecerá; é reduzir a probabilidade e o impacto de um incidente e estar preparado para investigar o que os registros mostram.

Além de compartilhar conhecimento no Nerd Cult, também trabalho com desenvolvimento de software. Se você tem uma aplicação .NET que precisa de melhorias ou está planejando um sistema novo, posso conversar sobre o projeto e ajudar a avaliar os próximos passos.

Posso ajudar em trabalhos como:

• Desenvolvimento e manutenção de aplicações web e APIs em C#/.NET;
• Revisão de acesso a dados com Entity Framework Core e consultas SQL;
• Implementação de validação, tratamento de erros, logs e Rate Limiting;
• Modernização de código legado e melhorias de manutenção;
• Análise inicial de problemas técnicos e definição de um plano de correção.

Uma revisão de código não substitui um teste de invasão ou uma auditoria de segurança especializada quando esse nível de avaliação é necessário. O primeiro passo é entender o sistema, o escopo e os riscos antes de definir o serviço adequado.

Se quiser conversar sobre um projeto, entre em contato pelo formulário disponível no Nerd Cult e descreva brevemente o sistema e o que precisa melhorar. Se o conteúdo foi útil, compartilhe este artigo com outro desenvolvedor ou responsável por uma aplicação web.

Para aprofundar os temas deste relato, confira também estes conteúdos do Nerd Cult:

• Como Resolver o Erro de Entity Tracking no Entity Framework Core — outro caso prático envolvendo EF Core;
• Como Ler Arquivos CSV Pesados em C# sem Travar a Memória — leitura de arquivos e processamento eficiente;
• C# vs Python para Automações — escolhas técnicas no ecossistema .NET.

Chamada para colaboração: você já identificou tentativas de SQL Injection, spam automatizado ou outro tipo de abuso em uma aplicação? Conte nos comentários quais sinais observou e quais medidas ajudaram. Não publique senhas, tokens, dados pessoais, endereços IP de terceiros ou detalhes que exponham um sistema vulnerável. Relatos responsáveis ajudam outros desenvolvedores a aprender sem aumentar o risco.

Seu sistema está preparado para receber tráfego abusivo?

Revise suas consultas, limite os envios dos formulários e monitore os registros. Se você precisa desenvolver ou melhorar uma aplicação .NET, entre em contato pelo formulário do Nerd Cult para conversar sobre o seu projeto.

Compartilhe o artigo com sua equipe e use a lista de verificações como ponto de partida para uma revisão técnica.

Nerd Cult — onde o código encontra o rock, o cinema e a cultura geek. Porque ser nerd é transformar o medo em curiosidade, e a curiosidade em poder.

#SQLInjection #SegurancaDeAplicacoes #EntityFrameworkCore #CSharp #DotNet #RateLimiting #ASPNetCore #NerdCult