Asymmetric denial of service - ReDoS - PHP

Asymmetric denial of service - ReDoS - PHP

Need

Mitigation of regular expression denial of service (ReDoS) vulnerabilities

Context

  • Usage of PHP 7.0 for server-side scripting and web development
  • Usage of Illuminate\\Http\\Request for handling HTTP requests in Laravel
  • Usage of Illuminate\\Support\\Facades\\Response for handling HTTP responses in Laravel
  • Usage of Illuminate\\Routing\\Controller for handling routes and controller logic in Laravel

Description

Non compliant code

        input('search');
        $regex = '/^([a-z0-9_-]{3,16}$)/'; // Dangerous regex

        if (preg_match($regex, $search)) {
            // Perform search operation
        } else {
            return response()->json(['error' => 'Invalid search query.']);
        }
    }
}
        
        

This PHP code snippet is part of a Laravel application and defines a method in the UserController class to handle search queries.

The search method takes a Request object as input and retrieves the 'search' field from it. This 'search' field is then checked against a regular expression (regex) to validate its format.

The vulnerability lies in the regular expression used: /^([a-z0-9_-]{3,16}$)/. This regex is intended to match any string of 3 to 16 characters that only contains lowercase letters, numbers, underscores, and hyphens.

However, this regular expression is vulnerable to a ReDoS (Regular expression Denial of Service) attack. ReDoS attacks exploit the fact that most regular expression implementations can be forced into taking a very long time when matching certain strings.

In this case, an attacker could send a specially crafted string that takes a long time to evaluate against the regex. For example, a string of 17 characters would cause the regex engine to backtrack excessively, potentially causing the server to hang or crash.

This is a serious vulnerability, as it can be exploited to perform a denial of service attack, rendering the application unavailable to legitimate users.

Steps

  • Identify the dangerous regular expressions in your code. In this case, the regular expression '/^([a-z0-9_-]{3,16}$)/' is identified as potentially dangerous.
  • Understand the purpose of the regular expression. This will help you determine how to modify it without breaking its intended functionality.
  • Modify the regular expression to make it safer. This could involve removing unnecessary groups, reducing the range of characters that can be matched, or limiting the length of the input that can be matched.
  • Test the modified regular expression to ensure it still functions as expected. This could involve running unit tests or manually testing it with various inputs.
  • Monitor the performance of the regular expression to ensure it does not cause any performance issues or vulnerabilities.

Compliant code

        input('search');
        $regex = '/^([a-z0-9_-]{1,10}$)/'; // Modified regex

        if (preg_match($regex, $search)) {
            // Perform search operation
        } else {
            return response()->json(['error' => 'Invalid search query.']);
        }
    }
}
        
        

The original code had a potential ReDoS (Regular Expression Denial of Service) vulnerability due to the use of a dangerous regular expression. The regular expression /^([a-z0-9_-]{3,16}$)/ was used to validate the search input from the user. This regular expression could potentially lead to a denial of service if an attacker sends a specially crafted string that causes the regular expression to take a long time to evaluate.

The fix involves modifying the regular expression to make it safer. The range of characters that can be matched has been reduced from {3,16} to {1,10}. This limits the length of the input that can be matched, reducing the potential for a ReDoS attack.

The modified code now uses the regular expression /^([a-z0-9_-]{1,10}$)/ to validate the search input. If the input does not match this regular expression, an error message is returned to the user.

This fix should prevent potential ReDoS attacks without affecting the intended functionality of the code. However, it is recommended to monitor the performance of the regular expression to ensure it does not cause any performance issues or vulnerabilities.

References