Sql Injection on Aws

SQL Injection in AWS environments often exploits the way developers interact with managed database services like Amazon RDS, Aurora, and DynamoDB (when using PartiQL). The attack surface extends beyond traditional web applications to serverless functions, API Gateway endpoints, and containerized services running on ECS or EKS.

A common pattern in AWS Lambda functions involves directly embedding user input into SQL queries without proper sanitization. Consider this vulnerable Node.js example using the AWS SDK with RDS:

const { RDSDataService } = require('aws-sdk');
const rds = new RDSDataService({ region: 'us-east-1' });

exports.handler = async (event) => {
  const userId = event.queryStringParameters.userId;
  const sql = `SELECT * FROM users WHERE id = ${userId}`;
  
  const params = {
    secretArn: 'arn:aws:secretsmanager:us-east-1:123456789012:secret:db-creds',
    resourceArn: 'arn:aws:rds:us-east-1:123456789012:cluster:your-cluster',
    sql,
    includeResultMetadata: true
  };
  
  const result = await rds.executeStatement(params).promise();
  return result.records;
};

An attacker could invoke this Lambda with ?userId=1 OR 1=1, causing the query to return all user records. The vulnerability is amplified in serverless architectures because a single compromised function can access the entire database backend.

Another AWS-specific scenario involves API Gateway with Lambda proxy integration. When API Gateway passes raw request data to Lambda, malicious SQL payloads can traverse through multiple layers:

# Malicious request
GET /users?userId=1; DROP TABLE users; -- HTTP/1.1
Host: api.example.com

Amazon Aurora Serverless functions present similar risks when developers use dynamic SQL generation. The combination of auto-scaling and pay-per-use pricing means a successful SQL injection attack could trigger numerous function invocations, potentially causing unexpected costs while extracting data.

Even when using AWS's managed services, developers often introduce vulnerabilities by not leveraging built-in protections. For instance, when using Amazon RDS with IAM authentication, some developers bypass the recommended authentication flow and instead use hardcoded credentials with dynamic SQL construction.

Detecting SQL Injection in AWS environments requires examining both application code and runtime behavior. middleBrick's black-box scanning approach is particularly effective for AWS APIs because it tests the actual attack surface without requiring source code access.

When scanning an AWS API endpoint, middleBrick tests for SQL Injection by sending payloads that target common database patterns. For a REST API backed by Lambda and RDS, the scanner might test:

# Test for MySQL injection
payload = "1' OR '1'='1"
# Test for PostgreSQL injection
payload = "1' OR '1' = '1' UNION SELECT NULL, version() --"
# Test for SQL Server injection
payload = "1' OR '1' = '1' UNION ALL SELECT NULL, @@version --"

The scanner analyzes responses for indicators like database error messages, timing differences, or unexpected data volumes that suggest SQL Injection vulnerabilities. middleBrick's 12 security checks include Input Validation testing specifically designed to catch these patterns.

For AWS-specific detection, middleBrick examines the OpenAPI specification if provided, looking for parameters that might be used in database queries. The scanner cross-references spec definitions with runtime findings, identifying mismatches between documented and actual behavior.

CloudWatch Logs analysis complements black-box scanning by revealing runtime SQL errors. A typical vulnerable pattern shows up as:

ERROR: syntax error at or near "DROP"
ERROR: unterminated quoted string at or near "'1' OR"

middleBrick's dashboard tracks these findings over time, showing whether vulnerabilities are introduced during deployments. The GitHub Action integration allows teams to fail builds when SQL Injection risks are detected in staging environments before production deployment.

API Gateway access logs can also reveal SQL Injection attempts through unusual query patterns or request sizes. middleBrick's continuous monitoring (Pro plan) can alert teams when new injection patterns are detected in production APIs.

Remediating SQL Injection in AWS environments starts with using parameterized queries with the AWS SDK. Here's a secure version of the earlier Lambda function:

const { RDSDataService } = require('aws-sdk');
const rds = new RDSDataService({ region: 'us-east-1' });

exports.handler = async (event) => {
  const userId = event.queryStringParameters.userId;
  
  const sql = 'SELECT * FROM users WHERE id = :userId';
  const parameters = [{ name: 'userId', value: { longValue: parseInt(userId) } }];
  
  const params = {
    secretArn: 'arn:aws:secretsmanager:us-east-1:123456789012:secret:db-creds',
    resourceArn: 'arn:aws:rds:us-east-1:123456789012:cluster:your-cluster',
    sql,
    parameters,
    includeResultMetadata: true
  };
  
  const result = await rds.executeStatement(params).promise();
  return result.records;
};

For Amazon Aurora Serverless, use prepared statements with the Data API:

const sql = 'SELECT * FROM users WHERE email = :email';
const parameters = [{ name: 'email', value: { stringValue: event.email } }];

When using Amazon RDS Proxy, leverage its built-in connection pooling and IAM authentication to reduce the attack surface. The proxy handles credential management, eliminating hardcoded secrets in Lambda functions.

For applications using Amazon DynamoDB, switch to PartiQL with parameterized queries:

const params = {
  secretArn: 'arn:aws:secretsmanager:us-east-1:123456789012:secret:db-creds',
  resourceArn: 'arn:aws:rds:us-east-1:123456789012:cluster:your-cluster',
  sql: 'SELECT * FROM "users" WHERE "id" = :id',
  parameters: [{ name: 'id', value: { longValue: userId } }]
};

Implement API Gateway request validation to reject malformed inputs before they reach your backend:

{
  "requestModels": {
    "application/json": "UserModel"
  },
  "requestValidatorId": "validator123"
}

Use AWS WAF with SQL Injection rules to provide an additional layer of protection at the API Gateway level. While not a substitute for proper input validation, it can block obvious injection attempts.

For Lambda functions, implement IAM policies with least privilege, ensuring database access is restricted to only necessary operations. This limits the potential impact if a function is compromised.

middleBrick's CLI tool can verify these remediations by scanning your API endpoints after implementing fixes, ensuring the SQL Injection vulnerabilities have been properly addressed.