Command Injection in Fiber with Dynamodb

Command Injection occurs when untrusted input is passed to system-level commands, and the combination of a Fiber-based Go API and direct DynamoDB interactions can create conditions where injection is possible through misuse of the SDK or unsafe handling of request parameters. While the AWS SDK for Go does not directly execute shell commands, developers sometimes construct shell commands or use helper utilities that incorporate DynamoDB attribute values without proper sanitization.

Consider a scenario where an API endpoint in Fiber accepts a user-supplied table name or key condition and passes it to a script or external process via exec.Command. If the DynamoDB table name or partition key value is taken directly from user input, an attacker can inject additional shell commands. For example, a table name like users; cat /etc/passwd could lead to unintended command execution if the input is concatenated into a shell string.

Even when using the official github.com/aws/aws-sdk-go/service/dynamodb package, injection risks arise when constructing expressions dynamically. If a developer builds a KeyConditionExpression by string concatenation using user input, and that input includes unexpected characters or reserved words, it can cause malformed requests or be leveraged in broader injection chains when those values are later logged, echoed, or passed to other subsystems that do interpret shell syntax.

In a typical vulnerable Fiber handler, the code might look like this, where a table name is taken directly from a query parameter and used in a DynamoDB API call without validation:

app.Get("/data", func(c *fiber.Ctx) error {
    tableName := c.Query("table")
    svc := dynamodb.New(session.New())
    input := &dynamodb.ScanInput{
        TableName: aws.String(tableName),
    }
    _, err := svc.Scan(input)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).SendString(err.Error())
    }
    return c.SendString("OK")
})

If table is not validated, an attacker could supply a value such as myTable && id (with URL encoding) which, if the application later uses this value in a shell context, may lead to command execution. Additionally, DynamoDB attribute values retrieved from the database might be stored in logs or error messages that are later processed by shell utilities, creating indirect injection opportunities.

The LLM/AI Security checks in middleBrick specifically test for unsafe consumption patterns where external inputs influence system behavior, including scenarios where DynamoDB outputs are handled by downstream processes. While the scan does not execute code, it identifies places where user-controlled data reaches sensitive execution paths.

Remediation focuses on strict input validation, avoiding shell command construction, and using the DynamoDB SDK as intended without string interpolation for control flow. Always treat user input as untrusted and avoid using it directly in system commands or dynamic expression building.

First, validate and restrict table names against a whitelist of known, safe values. Do not allow arbitrary table names from user input:

var allowedTables = map[string]bool{
    "users": true,
    "orders": true,
    "products": true,
}

app.Get("/data", func(c *fiber.Ctx) error {
    tableName := c.Query("table")
    if !allowedTables[tableName] {
        return c.Status(fiber.StatusBadRequest).SendString("invalid table name")
    }
    svc := dynamodb.New(session.New())
    input := &dynamodb.ScanInput{
        TableName: aws.String(tableName),
    }
    _, err := svc.Scan(input)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).SendString(err.Error())
    }
    return c.SendString("OK")
})

Second, when constructing DynamoDB expressions, use condition builders provided by the SDK instead of string concatenation. For example, use expression.NewKeyCondition to safely build key conditions:

import (
    "github.com/aws/aws-sdk-go/service/dynamodb"
    "github.com/aws/aws-sdk-go/service/dynamodb/expression"
)

keyCondition := expression.KeyConditionBuilder{
    PartitionKey: expression.Name("PK").Equal(expression.Value("user#123")),
}.Build()

input := &dynamodb.QueryInput{
    TableName:                 aws.String("users"),
    KeyConditionExpression:    keyCondition,
    ExpressionAttributeNames:  expression.Names{"#pk": "PK"},
    ExpressionAttributeValues: expression.Values{"val": &dynamodb.AttributeValue{S: aws.String("user#123")}},
}

Third, ensure that any logging or error handling does not inadvertently expose DynamoDB values to shell contexts. Sanitize outputs before writing to logs that might be consumed by external processes. The middleBrick CLI tool can be used to scan your endpoints with the command:

middlebrick scan https://api.example.com

For teams integrating security into development workflows, the GitHub Action can be added to CI/CD pipelines to automatically check scans and enforce risk thresholds before deployment.