[C#] Improve "isExponentialRegex" detection logic in ReDoSQuery.qll to prevent false negatives

Bắt đầu với csharp/ql/lib/semmle/code/csharp/security/dataflow/ReDoSQuery.qll, đặc biệt là các dòng 58–72, và theo dõi cách truy vấn cs/redos sử dụng isExponentialRegex và regexpMatch. So sánh logic matching hiện có với các ví dụ được liệt kê về các bộ định lượng lồng nhau và các nhánh thay thế chồng lấn. Được coi là hoàn tất khi truy vấn phát hiện được các biến thể này mà không làm mất phạm vi bao phủ hiện có hoặc tạo ra hành vi matching có vấn đề.

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