Regex Dos on Aws

Regular Expression Denial of Service (Regex DoS) occurs when attackers craft malicious input that causes catastrophic backtracking in poorly constructed regular expressions. In AWS environments, this vulnerability frequently appears in Lambda functions, API Gateway request validation, and CloudFront edge functions that process user input before routing requests.

A common pattern in AWS applications involves validating API parameters with regex before processing. Consider a Lambda function that validates email addresses:

const EMAIL_REGEX = /^([a-zA-Z0-9._%+-]+)@([a-zA-Z0-9.-]+)\.([a-zA-Z]{2,})$/;

This seemingly innocuous pattern can be exploited. An attacker sends input like:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@

The regex engine attempts to match the entire input, backtracking through thousands of possibilities. With nested quantifiers or complex patterns, this can cause the Lambda function to timeout (default 3 seconds) or consume excessive memory, leading to invocation failures.

In API Gateway, regex DoS can occur during request validation. AWS allows defining regex patterns in API models:

{
  "type": "object",
  "properties": {
    "username": {
      "type": "string",
      "pattern": "^[a-zA-Z0-9_.-]+$"
    }
  }
}

An attacker crafts input that forces exponential backtracking, causing API Gateway to delay responses or return 502 errors. This is particularly problematic in CloudFront distributions with Lambda@Edge functions that validate requests before forwarding to origin.

Another AWS-specific scenario involves S3 bucket policies with regex conditions. While less common, regex DoS can affect IAM policy evaluation when complex patterns are used in resource or principal definitions, potentially causing authentication delays.

Detecting Regex DoS in AWS requires both static analysis and runtime monitoring. middleBrick's black-box scanning approach is particularly effective for AWS APIs because it tests the actual attack surface without requiring access to source code.

When middleBrick scans an AWS API endpoint, it automatically tests for regex vulnerabilities by submitting crafted payloads designed to trigger backtracking. The scanner evaluates response times and error patterns to identify potential DoS conditions. For Lambda functions, middleBrick monitors for timeout patterns and memory exhaustion indicators.

AWS CloudWatch provides essential monitoring for regex DoS detection. Set up alarms on Lambda metrics:

{
  "Type": "AWS::CloudWatch::Alarm",
  "Properties": {
    "AlarmName": "RegexDoS_LambdaTimeout",
    "AlarmDescription": "Detects potential regex DoS attacks",
    "Namespace": "AWS/Lambda",
    "MetricName": "Duration",
    "Statistic": "Maximum",
    "Period": 60,
    "EvaluationPeriods": 1,
    "Threshold": 2500,
    "ComparisonOperator": "GreaterThanThreshold",
    "Dimensions": [
      {
        "Name": "FunctionName",
        "Value": "my-lambda-function"
      }
    ]
  }
}

This alarm triggers when any invocation exceeds 2.5 seconds, indicating potential regex processing issues.

For API Gateway, enable detailed CloudWatch metrics and set up anomaly detection. Monitor for unusual response time distributions and error rate spikes that correlate with specific endpoints or methods.

middleBrick's OpenAPI analysis feature is particularly valuable for AWS APIs. It analyzes your API specification and identifies regex patterns that could be vulnerable, then correlates these findings with runtime scan results to provide comprehensive risk assessment.

Remediating Regex DoS in AWS applications requires a multi-layered approach. Start with input validation using AWS-native services that provide built-in protection:

const { validate } = require('class-validator');
const { IsString, MaxLength } = require('class-validator');

class EmailDTO {
  @IsString()
  @MaxLength(254)
  email: string;
}

export const validateEmail = async (email: string) => {
  const dto = new EmailDTO();
  dto.email = email;
  
  const errors = await validate(dto);
  return errors.length === 0;
};

This approach uses class-validator, which provides safer validation than custom regex patterns.

For AWS Lambda, implement timeout protection and circuit breakers:

import { CircuitBreaker } from 'opossum';

const regexBreaker = new CircuitBreaker(async (input) => {
  // Your regex validation here
}, {
  timeout: 1000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000
});

export const handler = async (event) => {
  try {
    const result = await regexBreaker.fire(event.input);
    return {
      statusCode: 200,
      body: JSON.stringify({ success: true })
    };
  } catch (error) {
    return {
      statusCode: 429,
      body: JSON.stringify({ 
        error: 'Rate limit exceeded or processing timeout' 
      })
    };
  }
};

This implementation uses opossum to create a circuit breaker that trips if regex processing takes too long, preventing cascading failures.

In API Gateway, use request validation models with explicit length limits rather than complex regex patterns:

{
  "myApi": {
    "type": "object",
    "properties": {
      "username": {
        "type": "string",
        "maxLength": 50
      }
    },
    "required": ["username"]
  }
}

Combine this with AWS WAF rules to block suspicious patterns before they reach your backend:

{
  "Type": "AWS::WAFv2::WebACL",
  "Properties": {
    "Name": "RegexDoSWAF",
    "Scope": "REGIONAL",
    "DefaultAction": { "Allow": {} },
    "Rules": [
      {
        "Name": "LongInputFilter",
        "Priority": 1,
        "Action": { "Block": {} },
        "Statement": {
          "SizeConstraintStatement": {
            "FieldToMatch": { "Body": {} },
            "ComparisonOperation": "GT",
            "Size": 1000,
            "TextTransformations": [{"Priority": 0, "Type": "NONE"}]
          }
        }
      }
    ],
    "VisibilityConfig": {
      "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true,
      "MetricName": "RegexDoSMetrics"
    }
  }
}

This WAF rule blocks requests with bodies larger than 1000 characters, preventing large regex attacks from consuming backend resources.