[C#] Improve "isExponentialRegex" detection logic in ReDoSQuery.qll to prevent false negatives
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
Inizia da csharp/ql/lib/semmle/code/csharp/security/dataflow/ReDoSQuery.qll, in particolare dalle righe 58–72, e traccia il modo in cui la query cs/redos utilizza isExponentialRegex e regexpMatch. Confronta la logica di matching esistente con gli esempi elencati di quantificatori annidati e alternative sovrapposte. Il lavoro è completato quando la query rileva queste varianti senza perdere la copertura esistente né introdurre un comportamento di matching problematico.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- CodeQL
- Stelle
- 10.1k
- Fork
- 2.1k
- Merge medio
- 2g 11h
- PR unite (30g)
- 129
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di github/codeql
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
C#: cs/simplifiable-boolean-expression false positive on Nullable<bool> compared with a literal Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
false-positive
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
False positive Apertafalse-positive
Difficoltà 4/5 3-5 giorni Idoneità per principianti 15/100
Tutte le issue di github/codeql
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
TheManticoreProject/Manticore#1383 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
ethereum-optimism/factory#64 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
phoenixframework/phoenix#6847 ·
-
intake mcp-intake needs-ac needs-human-review priority:medium type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Ikalus1988/MisakaNet#2019 · 2 commenti ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
SocialiteProviders/Providers#1493 ·