Regra
Proteger contra lento regulares lentas.
As regulares com aninhados quantificadores ou 
ambíguos padrões podem causar catastróficos 
retrocesso e desempenho problemas.
Idiomas suportados: 45+

Introdução

As expressões regulares podem congelar a sua aplicação durante segundos ou minutos com a entrada correta. O retrocesso catastrófico ocorre quando os mecanismos de regex exploram caminhos exponencialmente crescentes enquanto tentam corresponder a um padrão. Uma regex como (a+)+b leva microssegundos para corresponder a uma entrada válida, mas pode levar horas para rejeitar uma sequência de a's sem um b final. Os atacantes exploram isso por meio de ataques de negação de serviço de expressão regular (ReDoS), enviando entradas criadas que fazem com que o mecanismo regex consuma 100% da CPU até que ocorram tempos limite de solicitação ou que o processo falhe.

Porque é importante

Implicações de segurança (ataques ReDoS): Um atacante pode paralisar a sua aplicação com um único pedido que contenha dados de entrada criados. A validação de correio eletrónico e os padrões de análise de URL são alvos comuns. Ao contrário dos ataques DoS tradicionais que requerem largura de banda, o ReDoS necessita apenas de pequenos payloads.

Degradação do desempenho: A entrada normal do utilizador pode desencadear um retrocesso catastrófico, fazendo com que os tempos de resposta aumentem de milissegundos para segundos. Isto cria uma latência imprevisível que é difícil de depurar porque só se manifesta com padrões de entrada específicos.

Incidentes de produção: O regex vulnerável bloqueia o loop de eventos no Node.js ou consome recursos do pool de threads. À medida que os pedidos se acumulam, a memória aumenta e o sistema deixa de responder. Nos microsserviços, um regex vulnerável causa falhas em cascata nos serviços dependentes.

Dificuldade de deteção: Os padrões que funcionam bem nos testes com entradas curtas tornam-se exponencialmente lentos com entradas mais longas. A vulnerabilidade passa frequentemente despercebida até à produção, exigindo uma implementação de emergência durante um incidente ativo.

Exemplos de código

Não conforme:

function validateEmail(email) {
    const regex = /^([a-zA-Z0-9_\-\.]+)+@([a-zA-Z0-9_\-\.]+)+\.([a-zA-Z]{2,5})$/;
    return regex.test(email);
}

function extractURLs(text) {
    const regex = /(https?:\/\/)?([\w\-])+\.(\w+)+([\w\-\.,@?^=%&:/~\+#]*)+/g;
    return text.match(regex);
}

Porque é que não é seguro: Os quantificadores aninhados ([a-zA-Z0-9_\\-\\.]+)+ criam um retrocesso exponencial. Para uma mensagem de correio eletrónico como aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!O motor regex tenta inúmeras combinações antes de falhar. O URL regex tem múltiplos quantificadores aninhados que agravam o problema, tornando-o trivialmente explorável com entradas como longas cadeias de caracteres válidos sem a estrutura esperada.

Conformidade:

function validateEmail(email) {
    const regex = /^[a-zA-Z0-9_\-\.]+@[a-zA-Z0-9_\-\.]+\.[a-zA-Z]{2,5}$/;
    return regex.test(email);
}

function extractURLs(text) {
    const regex = /https?:\/\/[\w\-]+\.[\w\-]+(?:[\w\-\.,@?^=%&:/~\+#]*)?/g;
    return text.match(regex);
}

Por que é seguro: A remoção de quantificadores aninhados elimina o retrocesso catastrófico. Quantificadores simples como [a-zA-Z0-9_\-\.]+ são executados em tempo linear. O padrão URL utiliza grupos não capturáveis com sufixo opcional (?:...)? em vez de repetição aninhada, garantindo um desempenho previsível independentemente do comprimento ou conteúdo da entrada.

Conclusão

O desempenho da expressão regular é uma preocupação de segurança, não apenas uma otimização. Reveja todos os padrões regex quanto a quantificadores aninhados, classes de caracteres sobrepostas em grupos de repetição e alternativas ambíguas. Teste os padrões regex com entradas patológicas (cadeias longas de caracteres válidos seguidos de finais inválidos) para identificar retrocessos catastróficos antes da implementação. Sempre que possível, substituir regex complexos por funções de análise de cadeias de caracteres que tenham caraterísticas de desempenho previsíveis.