[C#] Improve "isExponentialRegex" detection logic in ReDoSQuery.qll to prevent false negatives
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 48/100
Direção de pesquisa
Comece com csharp/ql/lib/semmle/code/csharp/security/dataflow/ReDoSQuery.qll, especialmente as linhas 58–72, e rastreie como a consulta cs/redos usa isExponentialRegex e regexpMatch. Compare a lógica de matching existente com os exemplos listados de quantificadores aninhados e alternativas sobrepostas. Considera-se concluído quando a consulta detectar essas variantes sem perder a cobertura existente nem introduzir um comportamento de matching problemático.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Hello,
In the C# security analysis suite, the query Denial of Service from comparison of user input against expensive regex (cs/redos) relies heavily on underlying helper logic to flag regular expressions with potential exponential behavior. Specifically, in csharp/ql/lib/semmle/code/csharp/security/dataflow/ReDoSQuery.qll (lines 58–72). This uses a set of hardcoded regular expressions via regexpMatch to identify string literals that represent exponential (ReDoS-vulnerable) regular expressions.
While these three variations catch patterns like ([a-z]+.)+, they are fragile syntactic approximations. This approach misses variations of overlapping or nested quantifiers, creating a scenario where dangerous regex structures easily bypass the query's detection due to minor structural variations.
For example the query overlooks risky patterns like these:
- Nested Quantifiers without literals:
(a*)*b or (x+)* - Overlapping Alternations/Sequences:
(x+x+)+y - Complex or Distant Structural Paths: Patterns that contain non-trivial prefixes/suffixes or specific character class structures can fail to match the strict capture-group structures defined in the QL code. Depending on the engine evaluating these meta-regexes, they could themselves face performance degradation when scanning highly complex, non-matching input paths.
This issue stood out because these specific pattern variants can easily slip through the ReDoS query undetected. This creates a gap between the security results and the actual risk. I'm wondering if it would be possible address this in a future version?
Version: 2.26.0
- Linguagem predominante
- CodeQL
- Estrelas
- 10.1k
- Forks
- 2.1k
- Merge médio
- 2d 10h
- PRs com merge (30d)
- 134
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de github/codeql
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
-
C#: cs/simplifiable-boolean-expression false positive on Nullable<bool> compared with a literal Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
false-positive
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
false-positive
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 68/100
Todas as issues de github/codeql
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
sipyourdrink-ltd/bernstein#6191 ·
-
security severity:low track:open-source
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
[addtool] DeepZero Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
gwen001/offsectools_www#2055 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
WalletConnect/actions#112 ·