Ssrf in Adonisjs with Dynamodb

Server-Side Request Forgery (SSRF) in an AdonisJS application that interacts with Amazon DynamoDB typically originates from unsafe usage of HTTP clients or metadata services rather than the DynamoDB client itself. AdonisJS, a Node.js web framework, often uses packages like axios or the built-in fetch to call external services. If these calls are constructed using user-supplied input—such as a URL or host provided in a request body or query parameter—an attacker can force the server to make arbitrary internal requests.

In a DynamoDB context, SSRF can emerge in two primary ways. First, if your AdonisJS backend accepts a table name, key condition expression, or endpoint override from the client and uses it to shape a DynamoDB request, you risk injection of metadata service targets (e.g., 169.254.169.254) into the logic that builds queries. Second, SSRF can occur when the application uses temporary AWS credentials retrieved from the instance metadata service; an SSRF payload can redirect or leak these credentials, enabling lateral movement within AWS.

Because DynamoDB operations are typically serverless and internal, the traditional network-based SSRF impact shifts to data exposure and AWS permission abuse. An attacker might not directly read DynamoDB tables via SSRF, but they can use the compromised host to probe internal AWS endpoints, enumerate IAM roles, or chain SSRF with other vulnerabilities (e.g., misconfigured S3 buckets) to escalate impact. The risk is amplified if the AdonisJS runtime has broad IAM permissions attached to its execution role, as is common in containerized or EC2-hosted environments.

To detect this with middleBrick, an unauthenticated scan would exercise endpoints that accept dynamic inputs and check whether the application reflects or acts on controlled URLs, especially those targeting 169.254.169.254 or internal AWS metadata. The LLM/AI Security checks included in middleBrick also probe for prompt injection and jailbreak techniques that might coax the application into making unintended network calls, which is relevant when AI-generated input is used to construct requests.

Remediation focuses on strict input validation, avoiding dynamic endpoint construction, and isolating DynamoDB operations from user-controlled data. In AdonisJS, you should never allow user input to directly specify AWS service endpoints or table names without a strict allowlist. Instead, use environment-based configuration and parameterized queries that treat user input as data, not as control instructions.

Below is a safe pattern for querying DynamoDB in AdonisJS using the AWS SDK v3. The example uses a hardcoded table name and validates input against a schema before constructing the command. This eliminates the possibility of an attacker steering the request toward a metadata service or arbitrary URL.

import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
import { marshall } from "@aws-sdk/util-dynamodb";
import { schema, rules } from "@ioc:Adonis/Core/Validator";

// Define a strict schema for incoming requests
const itemSchema = schema.create({
  userId: schema.string({}, [rules.uuid()]) // only accept valid UUIDs
});

export class UserProfileController {
  private readonly client = new DynamoDBClient({ region: process.env.AWS_REGION });
  private readonly tableName = process.env.DYNAMODB_TABLE; // set from env, not user input

  public async show({ request, response }) {
    const payload = request.validate({ schema: itemSchema });
    const command = new GetItemCommand({
      TableName: this.tableName,
      Key: marshall({ userId: payload.userId })
    });

    try {
      const data = await this.client.send(command);
      if (!data.Item) {
        return response.notFound({ error: "Not found" });
      }
      // Convert DynamoDB attribute values back to native types as needed
      return response.ok(data.Item);
    } catch (error) {
      // Log securely; do not expose raw errors to the client
      console.error("DynamoDB error:", error);
      return response.internalServerError({ error: "Unable to fetch profile" });
    }
  }
}

Additional remediation steps include:

• Disallow user-controlled URLs in any HTTP client calls within your AdonisJS routes or services.
• If you must accept a target, use an allowlist of known-safe endpoints and validate against it strictly.
• Ensure the IAM role attached to your runtime follows least privilege—avoid broad dynamodb:* permissions and scope access to specific tables and actions.
• Monitor for unusual patterns such as requests targeting 169.254.169.254 or other internal AWS metadata addresses, which may indicate active probing.

middleBrick’s scans can surface SSRF indicators by testing input vectors that attempt to reach internal endpoints and by analyzing your OpenAPI spec for overly permissive parameter usage. The platform’s findings include prioritized guidance and remediation steps tailored to the detected issue class.