Heurísticas de ReDoS para regex de aplicativos

O que é ReDoS em termos de aplicativos

Regular-expression Denial of Service ocorre quando uma entrada criada forces o mecanismo de correspondência a realizar um backtrack catastrófico. Os picos de CPU, a latência de solicitação explode e um único endpoint pode esgotar o processo. Isso não é uma trivialidade teórica: qualquer expressão regular em uma fronteira HTTP, linha de log ou nome de upload é um candidato se usar repetição arriscada.

Começo com a página ReDoS da OWASP e, em seguida, mapeio para as nossas rotas (OWASP ReDoS). A passagem heurística é intencionalmente monótona: encontrar quantificadores aninhados, alternância sobreposta e repetição ambígua em campos de entrada grandes.

Onde isso morde primeiro

- Validadores de e-mail / URL / "tag de texto livre" em formulários públicos - Regras de WAF ou gateway que reutilizam padrões de aplicativos - Regex de redação de log executado em cada linha - Validadores "strict" gerados por LLM com estrelas e pluses empilhados

Formas heurísticas para sinalizar imediatamente

Quantificadores aninhados, como (a+)+, (a*)* ou (a+)*, são a forma encontrada nos livros. Alternância sobreposta, como (a|a)+, ou prefixos compartilhados mais sutis, criam a mesma explosão. Grupos opcionais envoltos em repetição externa são fáceis de perder durante a revisão porque parecem organizados.

Também sinalize padrões que misturam repetição gulosa com uma condição trailing que frequentemente falha, porque o mecanismo percorre árvores enormes antes de rejeitar. Se você não consegue esboçar por que a correspondência é linear, trate-a como culpada até que se prove o contrário.

Lista de verificação — primeira passagem

- Qualquer quantificador dentro de outro quantificador na mesma cadeia de grupos - Ramos de alternância que podem corresponder ao mesmo prefixo -.* ou.+ ilimitados antes de um literal de falha em strings longas - Comprimento de entrada controlado pelo usuário sem limite rígido antes da execução do regex

Fluxo de trabalho passo a passo antes de um padrão atingir a produção

- Limite o comprimento da entrada na camada do framework antes que o regex seja executado. - Autor de fixtures: caminhos felizes curtos, strings de quase erro longas e algumas repetições adversárias. - Execute o padrão no mecanismo de produção com um orçamento de tempo (falhe no teste se exceder alguns milissegundos nos casos longos). - Reescreva a repetição aninhada em formas limitadas e mais claras — ou substitua regex por um analisador para dados estruturados. - Documente o risco residual quando você deve manter um padrão complexo, com um proprietário e uma data de revisão.

RegexProof destaca a repetição arriscada quando explica uma forja. Essa é uma primeira passagem, não uma prova de segurança sob todas as entradas.

Escolha do mecanismo como controle

Algumas implantações movem validadores quentes para mecanismos projetados para evitar o backtrack catastrófico (garantias do estilo RE2). Isso é um controle de arquitetura, não uma ajuste de regex. Se você permanecer em mecanismos de backtrack, como os típicos ECMAScript RegExp ou PCRE, você é responsável pela revisão do padrão. Leia o dialeto que você realmente executa: ECMA-262 RegExp para JavaScript, PCRE para muitas gateways.

Controle | O que ele oferece | O que ele não oferece Limite de comprimento de entrada | Limita o pior caso de trabalho | Correção do padrão Análise heurística para +/* aninhados | Captura formas comuns | Padrões lentos novos Testes unitários cronometrados | Sinal de regressão no CI | Prova contra todos os adversários Mecanismo não de backtrack | Remove uma classe inteira de risco | Paridade de recursos com brinquedos PCRE Revisão humana da saída do LLM | Para quantificadores empilhados precocemente | Garantia de perfeição

Erros comuns

- Supor que "é apenas validação" então ReDoS não se aplica - Copiar uma expressão regular de email estrita com repetição aninhada porque parece abrangente - Executar expressão regular em corpos de solicitação ilimitados - Confiar em uma explicação de gerador sem um teste cronometrado - Afirmar que "nunca perdemos ReDoS" em materiais de vendas — isso é uma superdeclaração

Critérios de decisão: reescrever, relocar ou manter

Reescrever quando o padrão é legível como uma pequena máquina de estado ou chamadas de biblioteca de strings. Relocar quando você precisa de correspondência rica, mas pode adiá-la para fora da thread de solicitação com timeouts estritos. Manter apenas quando os fixtures permanecem rápidos em entradas de near-miss longas e um proprietário aceita o risco residual ao escrever.

O que isso não é

Essas heurísticas não são uma prova formal, não são uma garantia de que o RegexProof encontra todos os padrões perigosos e não são um substituto para limites de entrada e timeouts. Nós não publicamos contagens de violações inventadas ou alegações de “detecção de 100%”. Use a lista de verificação para priorizar a revisão; mantenha o OWASP e a documentação do seu mecanismo abertos quando discutir sobre uma forma específica.

Como eu cronometro fixtures sem mentir para mim mesmo

Uma revisão ReDoS que usa apenas strings felizes e curtas sempre parecerá boa. Eu mantenho uma pasta de entradas quase certas: longas sequências do caractere repetido que o padrão ama, e então um trailer de falha. O teste falha se a correspondência excede um orçamento de milissegundos pequeno no executor de CI que usamos.

Se a equipe não puder concordar com um orçamento, comece com um limite conservador e aperte uma vez que você tenha baseline. O ponto é um sinal de regressão, não um artigo científico. Emparelhe o teste cronometrado com um limite de comprimento de entrada para que a produção nunca veja brinquedos em escala de megabyte.

Exemplos de perguntas de revisão

- Qual é a entrada mais longa que permitimos antes que a regex execute? - Qual grupo aninha um quantificador dentro de outro quantificador? - Duas ramificações de alternância podem consumir o mesmo prefixo? - Algum trabalho de redação de log reutiliza esse padrão em linhas ilimitadas? - Quem é o proprietário da reescrita se o tempo falhar no próximo mês?

Substituindo regex por código simples

Muitos validadores “inteligentes” são mais claros como split/join, analisadores de URL ou pequenos analisadores manuais. O código simples tem um comportamento linear que você pode ler. Eu movo formatos estruturados (UUIDs, datas com formas fixas, tokens simples) para longe do regex quando o padrão começa a coletar estrelas.

O regex ainda vence para lexing leve. A regra da honestidade é simples: se você não pode explicar o crescimento no pior caso, não coloque isso no caminho da solicitação.

Notas do operador para forjas assistidas por LLM

Modelos como quantificadores empilhados porque parecem precisos. Trate cada forja como não confiável até que a lista de verificação heurística e os fixtures temporizados sejam aprovados. As chamadas de casos de bordo do RegexProof são um filtro inicial. Seu orçamento de CI e os limites de entrada são os controles que mantêm o site ativo.

Ao escrever atualizações de status para as partes interessadas, diga o que você mediu (tempo de fixture, limite de entrada) em vez de afirmar proteção completa. Superdeclarações criam dívida de suporte quando o próximo padrão novo aparece.

Notas de campo: envio sem superestimar

Eu me recuso a usar linguagem de status que afirma que uma ferramenta nunca comete erros de dialecto ou formas de ReDoS. A linha honesta é: executamos testes no mecanismo de produção, limitamos o comprimento da entrada e revisamos quantificadores aninhados. O risco residual permanece sob a responsabilidade de uma pessoa nomeada.

Essa postura mantém os posts do blog alinhados com o que a RegexProof realmente vende — uma ferramenta com explicações e flags de casos de bordo — em vez de um scanner perfeito mítico. Os leitores que precisam de garantia formal ainda precisam realizar sua própria revisão de segurança.

Quando você ensina a um membro junior da equipe, peça que ele quebre um padrão propositadamente com uma string de quase-acerto longa. Ver o CPU subir ensina mais rápido do que outro aviso abstrato. Em seguida, corrija o padrão e mantenha o teste de unidade falho no CI para que a lição permaneça.

Por fim, mantenha as fontes primárias marcadas: ECMA-262 para o comportamento do RegExp JavaScript, documentos do PCRE para regras de gateway e OWASP para o modelo de ameaça do ReDoS. As ferramentas ajudam; o contrato ainda vive nessas referências.

Fechamento

Sinalize quantificadores aninhados e alternância sobreposta primeiro, limite o comprimento da entrada e cronometre seus testes no motor real. ReDoS é um bug de disponibilidade de aplicativos disfarçado de padrão inteligente. Mantenha a inteligência pequena o suficiente para explicar.

Fechando o loop após um fixture lento

Quando um fixture cronometrado falha, eu não aumento o orçamento primeiro. Eu reescrevo a repetição aninhada, adiciono um limite de entrada ou removo a verificação do caminho da solicitação. Aumentar o orçamento sem reescrever ensina o sistema a aceitar padrões lentos.

Anote os tempos do fixture antes e depois no ticket, para que o próximo revisor veja a melhoria. Mantenha a string adversária no CI para sempre. Esse único hábito evita regressões silenciosas quando alguém mais tarde simplifica o padrão sem reexecutar os casos longos.

Mantenha os fixtures adversários ao lado do arquivo de padrão, para que os revisores nunca precisem procurá-los.

Referências

- OWASP ReDoS - ECMA-262 RegExp - PCRE

Tente o produto: RegexProof

16-09-2026 · somente fontes primárias · sem métricas de tráfego fabricadas

Leituras relacionadas

- armadilhas de dialetos ecmascript-vs-pcre-2026 - A Matriz de Tópicos de Micro-SaaS de IA LX