Regex Dos in Aspnet with Bearer Tokens

A Regex Denial-of-Service (ReDoS) occurs when a regular expression has patterns that can cause catastrophic backtracking on certain inputs. In ASP.NET applications that use Bearer Tokens—typically passed in the Authorization header as Bearer {token}—regex-based validation of these tokens can become a high-risk vector if the pattern is poorly constructed.

Bearer tokens are often validated using regex to check format, length, or character set. For example, a developer might use a pattern like ^Bearer [a-zA-Z0-9-_=]+\.[a-zA-Z0-9-_=]+(\.[a-zA-Z0-9-_=]+)?$ to validate JWT-like tokens. While this appears reasonable, certain token structures can cause the regex engine to explore an exponential number of paths, especially when quantifiers are nested or when the token contains long repetitive segments of allowed characters.

The combination of Bearer Tokens and regex is risky because tokens often contain base64url-encoded segments with repetitive alphanumeric, hyphen, and underscore characters. A regex that uses patterns such as (a+)+ or [\w-]+ on long token strings can trigger catastrophic backtracking. In ASP.NET, this typically manifests during authentication middleware execution, where the framework evaluates the Authorization header against a defined regex before the request reaches application logic.

Real-world attack patterns mirror those seen in CVE-2021-44228 (Log4j) style injection reasoning but applied to validation layers: an attacker sends a long, specially crafted token designed to maximize backtracking. Because the scan methodology of middleBrick includes Input Validation checks, such regex-based weaknesses are detected as high-severity findings. The scanner tests token-like strings against your endpoint’s authentication regex patterns to uncover patterns that exhibit exponential time behavior.

An example of a vulnerable regex in an ASP.NET Core startup configuration might look like this, where the intent is to validate Bearer tokens but the pattern opens the door for ReDoS:

app.Use(async (context, next) =>
{
    var auth = context.Request.Headers["Authorization"].ToString();
    if (System.Text.RegularExpressions.Regex.IsMatch(auth, @"^Bearer ([a-zA-Z0-9-_=]+)+$"))
    {
        await next();
    }
    else
    {
        context.Response.StatusCode = 401;
    }
});

The nested quantifier ([a-zA-Z0-9-_=]+)+ is problematic because the outer + can match the same characters repeatedly, forcing the engine to attempt many paths. An input like Bearer aaaaa...aaaa (with sufficient length) can cause the regex evaluation to hang, consuming CPU and leading to a denial of service.

middleBrick’s 12 security checks run in parallel, and the Input Validation check specifically probes for such patterns by analyzing endpoint behavior against crafted tokens derived from OpenAPI specs and runtime exploration. Because the scanner references real OWASP API Top 10 categories, this finding is mapped to improper authentication handling, which can lead to unavailability via resource exhaustion.

To summarize, the vulnerability arises when regex validation of Bearer Tokens in ASP.NET uses repetitive quantifiers on user-controlled input without safeguards. The scanner detects this by testing token-like payloads and measuring response behavior, ensuring findings include severity and remediation guidance without attempting to fix the code automatically.

Remediation focuses on simplifying regex patterns, avoiding nested quantifiers, and offloading token validation to purpose-built libraries rather than custom regex. For Bearer Tokens, especially JWTs, the structure is typically three base64url-encoded segments separated by dots. You should validate format with a non-backtracking pattern and use standard libraries for deeper checks.

First, replace nested quantifiers with a pattern that matches the known token structure without repetition. Instead of ([a-zA-Z0-9-_=]+)+, use a pattern that matches exactly two dots and valid characters in each segment:

string tokenPattern = @"^Bearer [A-Za-z0-9-_]+\.[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+$";
if (System.Text.RegularExpressions.Regex.IsMatch(auth, tokenPattern, RegexOptions.Compiled))
{
    // Proceed to further validation
}

This pattern avoids nested quantifiers and uses RegexOptions.Compiled to improve performance. It ensures the token has the expected JWT-like shape without catastrophic backtracking possibilities.

Second, consider using the System.IdentityModel.Tokens.Jwt library to parse and validate tokens instead of regex. This removes regex entirely from the validation path and leverages well-tested implementations:

using System.IdentityModel.Tokens.Jwt;
using Microsoft.IdentityModel.Tokens;

var handler = new JwtSecurityTokenHandler();
var validationParams = new TokenValidationParameters
{
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your-secret-key")),
    ValidateIssuer = false,
    ValidateAudience = false,
    ClockSkew = TimeSpan.Zero
};

try
{
    SecurityToken validatedToken;
    var principal = handler.ValidateToken(authHeader.Replace("Bearer ", ""), validationParams, out validatedToken);
    // Token is valid, proceed with request
}
catch (SecurityTokenException)
{
    context.Response.StatusCode = 401;
}

This approach is resilient against malformed tokens and does not rely on regex, thus eliminating ReDoS risk from token validation.

Third, if you must use regex, pre-test patterns with long repetitive inputs in a safe environment and ensure the regex engine’s backtracking is bounded. For ASP.NET middleware, you can also short-circuit validation by checking token length before applying regex:

string auth = context.Request.Headers["Authorization"].ToString();
if (auth.StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase) && auth.Length <= 500)
{
    if (Regex.IsMatch(auth, @"^Bearer [A-Za-z0-9-_.~+/=]+$"))
    {
        await next();
    }
    else
    {
        context.Response.StatusCode = 401;
    }
}
else
{
    context.Response.StatusCode = 400;
}

By combining length checks, simpler character classes, and avoiding nested quantifiers, you reduce the attack surface. middleBrick’s Continuous Monitoring in the Pro plan can alert you if future changes introduce risky patterns, and the GitHub Action can fail builds when risk scores exceed your defined thresholds.

In summary, remediate by using non-backtracking patterns, leveraging JWT libraries, and adding length and format guards. These steps align with findings mapped to frameworks like OWASP API Top 10 and can be integrated into your CI/CD pipeline using middleBrick’s tooling.