Uploaded image for project: 'Rules Repository'
  1. Rules Repository
  2. RSPEC-5852

Using slow regular expressions is security-sensitive

    Details

    • Type: Security Hotspot Detection
    • Status: Active
    • Resolution: Unresolved
    • Labels:
    • Message:
      Make sure this regex cannot lead to denial of service here.
    • Default Severity:
      Critical
    • Impact:
      High
    • Likelihood:
      Low
    • Default Quality Profiles:
      Sonar way
    • Targeted languages:
      C#, C, C++, Java, JavaScript, Kotlin, Objective-C, PHP, Python, VB.Net
    • Remediation Function:
      Constant/Issue
    • Constant Cost:
      30min
    • Analysis Scope:
      Main Sources, Test Sources
    • CWE:
      CWE-400

      Description

      Most of the regular expression engines use backtracking to try all possible execution paths of the regular expression when evaluating an input, in some cases it can cause performance issues, called catastrophic backtracking situations. In the worst case, the complexity of the regular expression is exponential in the size of the input, this means that a small carefully-crafted input (like 20 chars) can trigger catastrophic backtracking and cause a denial of service of the application. Super-linear regex complexity can lead to the same impact too with, in this case, a large carefully-crafted input (thousands chars).

      This rule detects regular expression patterns known to have potential performance issues:

      • Nested quantifiers which are quantifiers inside a group that is itself repeated by a quantifier (eg: /(a+)+/).

      Ask Yourself Whether

      • The input is user-controlled.
      • The input size is not restricted to a small number of characters.
      • There is no timeout in place to limit the regex evaluation time.

      There is a risk if you answered yes to any of those questions.

      Recommended Secure Coding Practices

      To avoid catastrophic backtracking situations, when possible:

      • The maximum number of expected repetitions should be defined with the corresponding quantifier, like {1,5} instead of + for instance.
      • Refactor nested quantifiers to limit the number of way the inner group can be matched by the outer quantifier, for instance this nested quantifier situation (ba+)+ doesn't cause performance issues, indeed, the inner group can be matched only if it exists exactly one b char per repetition of the group.
      • Optimize regular expressions with possessive quantifiers and atomic grouping.

      See

        Attachments

          Issue Links

          1.
          Java RSPEC-5858 Language-Specification Active Unassigned

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                eric.therond Eric Therond
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: