[C#] Improve "isExponentialRegex" detection logic in ReDoSQuery.qll to prevent false negatives
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
Rechercherichtung
Beginne mit csharp/ql/lib/semmle/code/csharp/security/dataflow/ReDoSQuery.qll, insbesondere mit den Zeilen 58–72, und verfolge, wie die Abfrage cs/redos isExponentialRegex und regexpMatch verwendet. Vergleiche die bestehende Matching-Logik mit den aufgeführten Beispielen für verschachtelte Quantifizierer und sich überschneidende Alternativen. Als erledigt gilt die Aufgabe, wenn die Abfrage diese Varianten erkennt, ohne ihre bestehende Abdeckung zu verlieren oder problematisches Matching-Verhalten einzuführen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- CodeQL
- Sterne
- 10.1k
- Forks
- 2.1k
- Ø Merge
- 2 T. 16 Std.
- Gemergte PRs (30 T.)
- 143
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus github/codeql
-
agentic-workflows
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
false-positive javascript
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
-
C#: cs/simplifiable-boolean-expression false positive on Nullable<bool> compared with a literal Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
false-positive
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
Ähnliche Issues
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
canonical/paas-charm#368 · 1 Kommentar ·
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
palladius/rails8-app-on-gcp#142 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
StevenBlack/hosts#3256 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
corsairdev/corsair#1764 ·
-
oblt-aw/detector/security
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100