Quando as expressões regulares se voltam contra o desempenho
Uma única linha de expressão regular em C# pode levar uma API de produção ao colapso. Padrões mal escritos desencadeiam backtracking catastrófico, consumindo ciclos de CPU e bloqueando threads. Este é o clássico exemplo disso. Negação de serviço por expressão regular (ReDoS), um vetor de ataque sutil, porém perigoso, oculto em seu código.
⚠️Exemplo inseguro, apenas para fins educacionais. Não utilize em produção.
string pattern = @"(a+)+$"; // Vulnerable regex c#
Regex regex = new Regex(pattern);
bool isMatch = regex.IsMatch("aaaaaaaaaaaaaaaaaaaaaaaa!");
Esta expressão regular para C# sofre com quantificadores aninhados que causam retrocesso exponencial. Uma string longa e maliciosa pode congelar um endpoint ou um microsserviço.
Versão segura:
string pattern = @"^a+$"; // Safe simplified regex for C#
Regex regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(200));
bool isMatch = regex.IsMatch("aaaaaaaaaaa");
Nota educacional: Sempre use tempos limite (Opções de expressão regular + Intervalo de tempo) e simplificar grupos aninhados. Em expressões regulares em C#, a validação de desempenho é um requisito de segurança, não uma otimização.
Por que os padrões de expressões regulares em C# se tornam vulneráveis?
Quantificadores ambíguos (.*, .+, ou (a+)+) e a repetição ilimitada fazem das expressões regulares um alvo comum de ataques de negação de serviço (DoS).
Quando esses comandos aparecem em contextos controlados pelo usuário, como validação de entrada ou análise de logs, uma única carga útil cuidadosamente elaborada pode monopolizar a CPU.
⚠️Exemplo inseguro, apenas para fins educacionais. Não utilize em produção.
// Vulnerable email validation regex for C#
var pattern = @"^([a-zA-Z0-9_\-\.]+)@([\w\-]+\.)+([a-zA-Z]{2,4})$";
var input = "a".PadLeft(10000, 'a') + "@example.com";
Regex.IsMatch(input, pattern); // May hang or cause ReDoS
Versão segura:
// Safer regex c# pattern
var pattern = @"^[^@\s]+@[^@\s]+\.[^@\s]+$";
Regex regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(300));
bool isValid = regex.IsMatch("user@example.com");
Nota educacional: Evite repetições ambíguas, limite o tamanho da entrada e sempre teste o desempenho das expressões regulares sob carga. Trecho funcional: imponha tempos limite e limite máximo de entrada como medidas de segurança em produção.
Impacto real em APIs e CI/CD Fluxos de trabalho
Expressões regulares inseguras em C# não se limitam a formulários de validação. Desenvolvedores incorporam padrões em filtros de log, correspondências de webhook e varreduras automatizadas. CI/CDUm único padrão inseguro pode paralisar todo o sistema. pipeline.
⚠️Exemplo inseguro, apenas para fins educacionais. Não utilize em produção.
// Regex used to match commit messages in a CI job
var regex = new Regex(userInputPattern);
if (regex.IsMatch(commitMessage)) { /* process */ }
If userInputPattern contains (a+)+$, it can freeze the build agent.Nunca processe expressões regulares fornecidas pelo usuário sem validação ou controle de tempo limite.
Versão segura:
// Safe usage in CI/CD context
if (userInputPattern.Length < 100 && !userInputPattern.Contains("++"))
{
Regex regex = new Regex(userInputPattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(100));
if (regex.IsMatch(commitMessage)) { /* safely process */ }
}
Nota educacional: Valide a entrada de expressões regulares externas antes da execução. Adicione verificações explícitas de comprimento e imponha tempos limite em pipelines.
Práticas seguras para prevenir ataques DoS com expressões regulares em C#
A prevenção de ataques ReDoS em expressões regulares C# deve ser incorporada ao seu desenvolvimento. Fluxo de trabalho DevSecOps. Veja como torná-lo seguro por padrão:
Melhores Práticas
- Defina sempre os tempos limite. em todas as avaliações de expressões regulares.
- Evite padrões catastróficos, sem quantificadores aninhados ou grupos ambíguos.
- Limitar o tamanho da entrada antes de passar para a expressão regular.
- Pré-compilar padrões confiáveis com as RegexOptions.Compilado.
- Higienizar expressões fornecidas pelo usuário ou adicione padrões permitidos à lista de permissões.
Mini lista de verificação preventiva
- Analise todas as expressões regulares para uso em C# em sua base de código.
- Inscreva-se Intervalo de tempo timeouts constantes.
- Limitar o tamanho dos dados inseridos na API e nas entradas de CI.
- Testar o desempenho das expressões regulares antes do lançamento.
- Automatizar expressões regulares estáticas digitalização CI/CD.
Nota educacional: Trate os padrões de expressões regulares como código não confiável. Eles merecem a mesma atenção que o SQL ou a execução de comandos.
Como o Xygeni detecta o uso arriscado de expressões regulares em C#
Xygeni Segurança de Código Detecta automaticamente padrões de expressões regulares inseguros em C# durante a análise estática. Ele identifica retrocessos catastróficos, timeouts ausentes e padrões que provavelmente travam os serviços. In CI/CD, Xygeni age como um DevSecOps gate, bloqueando expressões regulares inseguras para C# antes de serem mescladas ou implantadas.
# Never expose real tokens, credentials, or internal URLs in pipelines
- name: Regex Safety Scan
run: dotnet xygeni validate --rules regex ,performance --fail-on-riskNota educacional: A integração do Xygeni garante o tratamento seguro de expressões regulares em todas as compilações e ambientes, prevenindo regressões e exposição a ataques de negação de serviço (DoS) antes da implantação.
Sua expressão regular é poderosa, certifique-se de que ela não seja usada como arma.
Vulnerabilidades ReDoS transformam expressões regulares C# aparentemente inofensivas em armas de negação de serviço. Expressões regulares inseguras para padrões C# são um descuido comum, que pode causar problemas sérios, como congelamento da produção ou falhas. CI/CD.
Incorpore a segurança de expressões regulares à sua rotina de programação:
- Use sempre tempos limite.
- Evite quantificadores aninhados.
- Restringir a entrada do usuário.
- Automatize verificações usando Xygeni Segurança de Código.
Expressões regulares sempre serão poderosas, mas com um design cuidadoso, seus padrões de expressões regulares em C# não se tornarão seu próximo relatório de incidente.
