Regex Dos in Fiber with Basic Auth

A Regular Expression Denial of Service (Regex DoS) can occur in Fiber when route path patterns or validation logic use poorly constructed regular expressions that exhibit catastrophic backtracking. When Basic Authentication is enforced via middleware, the server must evaluate credentials before reaching route handlers. If the Basic Auth check or subsequent route matching uses a complex or non-anchored regex against untrusted input (such as usernames, passwords, or URL paths), an attacker can craft inputs that cause exponential time consumption.

Consider a scenario where a Fiber app uses a regex to validate a header or path parameter and also applies Basic Auth middleware. The combination means the regex is evaluated for each authenticated request. If the regex has overlapping quantifiers (e.g., (a+)+) or optional repetitions against unbounded input, an attacker can send a specially crafted string that forces the runtime into excessive backtracking. During this processing, the event loop is blocked, causing request delays that manifest as service degradation. In a black-box scan, middleBrick tests such inputs against the unauthenticated attack surface; if a route or auth check uses vulnerable patterns, the scan may flag findings related to Input Validation and identify risk paths that can be triggered without credentials.

Example of a vulnerable pattern in a Fiber route definition:

const escapeHtml = require('escape-html');
const app = require('express')(); // Using express-style patterns for illustration
app.get('/files/:name', (req, res) => {
  const match = req.params.name.match(/^(a+)+\.txt$/);
  if (!match) return res.status(400).send('Invalid');
  res.send('OK');
});

In this example, the regex ^(a+)+\.txt$ is vulnerable to catastrophic backtracking with inputs like aaaa...x!txt where the engine tries many permutations before failing. If Basic Auth middleware precedes this handler, the attacker does not need valid credentials to trigger the DoS; the malicious path alone consumes excessive CPU. The scan will identify the risky input validation logic and highlight it under the Input Validation checks.

Another scenario involves Basic Auth parsing. If the app decodes the Authorization header and applies a regex to the username or password without constraints, an attacker can supply long or repetitive strings that cause backtracking. For instance, extracting the credentials with a non-anchored pattern or using repetitive capture groups can amplify processing time. Because middleBrick evaluates unauthenticated endpoints, it can probe endpoints protected by Basic Auth by sending malformed credentials and analyzing responses, exposing whether regex handling contributes to instability.

To map this to real-world references, patterns like these resemble issues flagged under CWE-1333 (Excessive Computation) and can intersect with OWASP API Top 10’s Invalid API Input. The presence of Basic Auth does not introduce the regex flaw, but it ensures the regex is evaluated on every request, increasing the impact of a vulnerable pattern. A scan that includes authentication checks will still test the unauthenticated surface, but developers must audit both route definitions and auth logic to ensure regex patterns are linear and bounded.

Remediation focuses on making regex patterns safe and avoiding unnecessary complexity in both route matching and credential parsing. Use non-backtracking constructs, anchor expressions, and prefer simple character class checks. In Fiber, implement Basic Auth with explicit string operations instead of regex where possible, and ensure any regex is linear and bounded.

Secure route validation example in Fiber:

const app = require('express')(); // Illustration; adapt to Fiber idioms
app.get('/files/:name', (req, res) => {
  // Use a simple character check instead of a complex regex
  const name = req.params.name;
  if (!/^[a-zA-Z0-9._-]+\.txt$/.test(name)) {
    return res.status(400).send('Invalid');
  }
  res.send('OK');
});

The updated regex ^[a-zA-Z0-9._-]+\.txt$ is anchored, uses a single repetition quantifier, and avoids nested quantifiers that cause backtracking. This pattern accepts only safe filenames ending in .txt.

Basic Auth implementation example without vulnerable regex parsing:

const http = require('http');
const app = require('express')();

// Basic Auth middleware using direct string comparison
app.use((req, res, next) => {
  const authHeader = req.headers['authorization'];
  if (!authHeader || !authHeader.startsWith('Basic ')) {
    res.set('WWW-Authenticate', 'Basic realm="Access"');
    return res.status(401).send('Auth required');
  }
  const base64 = authHeader.split(' ')[1];
  const decoded = Buffer.from(base64, 'base64').toString('utf-8');
  const [user, pass] = decoded.split(':');
  // Avoid regex on user/pass; use constant-time comparison for secrets if needed
  if (user === 'admin' && pass === 's3cret') {
    return next();
  }
  res.status(403).send('Forbidden');
});

app.get('/secure', (req, res) => {
  res.send('Authenticated');
});

app.listen(3000);

This approach avoids regex entirely for credential validation and uses straightforward string checks. If pattern matching on credentials is necessary, ensure patterns are anchored and non-backtracking. For example, validating an API key with a safe regex:

const API_KEY_PATTERN = /^[A-F0-9]{32}$/; // Hex string, fixed length, anchored
if (!API_KEY_PATTERN.test(userSuppliedKey)) {
  // reject
}

Additionally, apply rate limiting and monitoring to reduce the impact of potential abuse. middleBrick scans can verify that no vulnerable regex patterns remain in route definitions or validation logic, and findings will include remediation guidance tied to Input Validation and related checks.