Regex Checks - SonarSource/sonar-java GitHub Wiki

Regular Expression Checks

Regex Helpers

AbstractRegexCheck

RegexTreeHelper

Parser

AST

Automaton

Automata-based analyses for regular expressions

In order to analyze control flow within regular expressions, they should be represented as an "AST extended with continuation pointers" model as is used by some reDoS analyzers and similar to the representation used in Java's regex engine. This model provides the features of a prioritized (order of alternatives matters) NFA while still providing access to the AST structure. Since this kind of automaton is just an AST with extra pointers, we should extend the current AST classes to support it and then generate it directly in the parser rather than having separate regex -> AST -> automaton phases.

For example:

To represent this, each AST class should have a member continuation that points to whichever state should be matched after this one is matched successfully. To be able to easily and intuitively use this as an NFA, we should also add a method successors which returns the states that can directly follow a given state. With these methods, we get the structure of an NFA, while requiring no changes to existing rules that can simply continue using the existing structure without changes.

For easy construction in the parser, the continuation member should be null when constructed and then set using a setter method. However, after parsing the states should be considered immutable and the setter should not be called anymore.

To represent some aspects of Java regexen, we need synthetic states that don't correspond directly to parts of the AST. Therefore we should introduce an interface AutomatonState such that RegexTree implements AutomatonState, all AutomatonState s have a continuation and a list of successors (which are also AutomatonState s) and RegexTree s have children (which are RegexTree s). The children member can also be used to simplify the implementation BaseRegexTreeVisitor (which should still only visit RegexTree s - the synthetic states should not be visible when iterating a regex's syntactic structure only when iterating the states of the automaton via successors and/or continuation). The following synthetic AutomatonState s should be created:

  • StartState represents the initial state of the automaton. Its continuation and successor will be the RegexTree representing the whole regex. It will be accessible through the RegexParseResult object created by the parser.

    images/automaton/doc-2-synthetic-states-start.A.png

  • Branch represents a branch in the control flow that does not correspond to the direct use of the | operator. The difference between Branch and Disjunction is that the latter corresponds directly to a syntax construct (and thus inherits RegexTree) while the latter does not. Therefore both should implement a common interface, so they can be handled as the same thing by rules that deal with automata states.

    images/automaton/doc-2-synthetic-states-branch.A.png

  • EndOfRegex represents the end of the regex being reached successfully. It's the automaton's only accepting state. Its continuation should be null.

    images/automaton/doc-2-synthetic-states-end-of-regex.png

  • EndOfLookAround represents the end of a look around group. Reaching the end of a positive look around will cause the match to continue at the point where the look around began. It should contain a reference to the LookAroundTree whose end it represents.

    images/automaton/doc-2-synthetic-states-end-of-look-around.A.png

  • Negation introduces a negated section of the automaton (created by negative lookarounds). There should be no transitions from the negated section back to the non-negated part (which makes it important that EndOfLookAround has no continuation/successors).

    images/automaton/doc-2-synthetic-states-negation.A.png

Each AutomatonState should have an transitionType to represent the type of its incoming transitions (all incoming transitions of a state will be of the same type (and with the same label) in this representation). The following transition types should exist:

The continuations and successors of states should be set as follows by the parser: