Information Disclosure on Aws

Information disclosure in Aws applications occurs when sensitive data is unintentionally exposed through API responses, error messages, or debug information. Aws's serverless architecture and microservices patterns create unique disclosure vectors that differ from traditional web applications.

The most common Aws-specific disclosure pattern involves Lambda function error responses. When a Lambda function throws an exception, Aws automatically serializes the error object and returns it in the response body. This often includes stack traces, environment variable contents, and internal implementation details:

exports.handler = async (event) => {
  try {
    const secret = process.env.DATABASE_PASSWORD;
    // ... use secret
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({
        message: error.message,
        stack: error.stack, // Sensitive stack trace exposed
        env: process.env // Entire environment exposed
      })
    };
  }
};

API Gateway integration amplifies this problem. When API Gateway passes through Lambda errors without proper configuration, the full error object becomes part of the HTTP response body. Attackers can extract database connection strings, AWS region information, and IAM role permissions from these responses.

Another Aws-specific disclosure vector is CloudWatch log exposure. Developers often include debug logging that captures sensitive request parameters, headers, or payload contents. If CloudWatch logs are not properly secured with IAM policies, unauthorized users can access these logs through the AWS console or APIs.

Serverless cold starts can also trigger information disclosure. During initialization, Lambda functions may log sensitive configuration data, database connection attempts, or third-party service credentials. These logs persist in CloudWatch and become discoverable attack surface.

Aws SAM templates and CloudFormation templates often contain hardcoded secrets or credentials that get deployed to production. If these templates are stored in version control or shared repositories, they expose infrastructure-level secrets.

Detecting information disclosure in Aws requires both static analysis of code and dynamic scanning of deployed endpoints. The serverless nature of Aws means traditional web application scanners miss critical Aws-specific disclosure patterns.

middleBrick's Aws-specific detection capabilities include scanning Lambda function responses for sensitive data patterns. The scanner identifies exposed stack traces, environment variables, and error details in API Gateway responses. It also checks for CloudWatch log configuration issues that might expose sensitive data.

Key detection patterns for Aws applications:

// middleBrick scan output example
{
  "endpoint": "https://api.example.com/users",
  "checks": {
    "information_disclosure": {
      "status": "FAIL",
      "severity": "HIGH",
      "findings": [
        {
          "type": "error_response_disclosure",
          "description": "Lambda error response contains stack trace and environment variables",
          "remediation": "Implement custom error handling and sanitize error responses",
          "location": "handler.js:42-58"
        }
      ]
    }
  }
}

middleBrick also scans for Aws-specific configuration issues like overly permissive IAM roles, exposed CloudWatch log groups, and insecure API Gateway settings. The scanner tests for common disclosure vectors by sending malformed requests that trigger error conditions, then analyzing the responses for sensitive information.

For LLM/AI security, middleBrick detects if Aws applications are using exposed AI services without proper input validation. This includes checking for prompt injection vulnerabilities in applications using Amazon Bedrock or other Aws AI services.

The scanner validates that error handling middleware properly sanitizes responses before they reach API Gateway. It checks for missing error boundaries in Lambda functions that could allow unhandled exceptions to expose internal state.

Remediating information disclosure in Aws requires implementing proper error handling patterns and securing the serverless execution environment. Aws provides native features that help prevent information leakage.

Implement structured error handling in Lambda functions:

const createErrorResponse = (error) => {
  const sanitizedError = {
    message: error.message || 'Internal Server Error',
    code: error.statusCode || 500
  };
  
  // Log full error internally without exposing to client
  console.error('API Error:', {
    message: error.message,
    stack: error.stack,
    timestamp: new Date().toISOString()
  });
  
  return {
    statusCode: sanitizedError.code,
    body: JSON.stringify({
      error: {
        message: sanitizedError.message,
        // Never expose stack traces or internal details
        code: sanitizedError.code
      }
    }),
    headers: {
      'Content-Type': 'application/json'
    }
  };
};

exports.handler = async (event) => {
  try {
    // ... application logic
    return {
      statusCode: 200,
      body: JSON.stringify({ data: 'success' })
    };
  } catch (error) {
    return createErrorResponse(error);
  }
};

Configure API Gateway to mask Lambda errors:

const maskLambdaErrors = (error) => {
  return {
    statusCode: error.statusCode || 500,
    body: JSON.stringify({
      error: 'An unexpected error occurred. Please try again later.'
    })
  };
};

// In API Gateway integration response mapping
// Set integration.response.body to mask detailed errors

Secure CloudWatch logs with IAM policies:

const cloudWatchPolicy = {
  Version: '2012-10-17',
  Statement: [
    {
      Effect: 'Allow',
      Action: [
        'logs:CreateLogGroup',
        'logs:CreateLogStream',
        'logs:PutLogEvents'
      ],
      Resource: 'arn:aws:logs:*:*:*'
    },
    {
      Effect: 'Deny',
      Action: 'logs:GetLogEvents',
      Resource: 'arn:aws:logs:*:*:*',
      Principal: '*' // Restrict log access to authorized users only
    }
  ]
};

Implement input validation and sanitization:

const sanitizeInput = (input) => {
  if (typeof input !== 'object') return input;
  
  const sanitized = {};
  for (const [key, value] of Object.entries(input)) {
    if (key.toLowerCase().includes('password') || 
        key.toLowerCase().includes('secret') ||
        key.toLowerCase().includes('token')) {
      sanitized[key] = 'REDACTED';
    } else {
      sanitized[key] = typeof value === 'object' ? sanitizeInput(value) : value;
    }
  }
  return sanitized;
};

exports.handler = async (event) => {
  const sanitizedEvent = sanitizeInput(event);
  // Process sanitized input
};

Use Aws X-Ray for debugging instead of console logging sensitive data. X-Ray provides tracing without exposing sensitive information in logs.

Implement proper IAM role permissions with least privilege. Avoid wildcard permissions that could allow unauthorized access to logs or other Aws resources.