Nosql Injection in Echo Go with Dynamodb

NoSQL injection in an Echo Go service that uses Amazon DynamoDB typically occurs when user input is interpolated into DynamoDB expressions rather than being handled through parameterized constructs. DynamoDB’s low-level API and expression syntax allow attribute names and values to be supplied separately, but if an application builds expression strings by concatenating unchecked input, it can alter query semantics in unsafe ways.

Consider an endpoint in Echo Go that retrieves a user profile by user ID. If the handler reads a path parameter (e.g., userID) and directly embeds it into a KeyConditionExpression or FilterExpression, an attacker can supply values like user123 OR attribute_exists(admin) or manipulate reserved words to change which items are returned. Because DynamoDB does not parse expressions as structured types when built via string concatenation, the injected logic may bypass intended filters.

In Echo Go, a vulnerable route might look like this on the server side:

c.Bind(&input) // input contains user-controlled fields used in expression building
expr := "userID = '" + input.UserID + "'"
input := &dynamodb.ScanInput{
    TableName: aws.String("Users"),
    FilterExpression: aws.String(expr),
}
_, err := svc.Scan(context.TODO(), input)

Here, input.UserID is concatenated into the expression string. An attacker providing hacker' OR attribute_exists(isAdmin) can change the logical intent of the filter. Although DynamoDB treats the value as a literal in many cases, expression syntax for operators and function names can be abused if attribute names or reserved keywords are involved. For example, supplying userID as xyz AND begins_with(status, 'A') in a KeyConditionExpression may cause the query to scan more items than intended, leading to data exposure or privilege escalation.

Additionally, DynamoDB’s reserved words (e.g., status, value) can be targeted. If an attacker injects an expression like 1=1; status = :status where the application misuses expression separators or fails to validate input, they might affect conditional writes or scans. While DynamoDB SDKs support expression attribute names and values to prevent injection, Echo Go handlers that bypass these mechanisms expose the unauthenticated attack surface that middleBrick would flag under BOLA/IDOR and Input Validation checks.

To remediate NoSQL injection in Echo Go when working with DynamoDB, always use the SDK’s expression builders and never concatenate user input into expression strings. Use dynamodbattributes for marshaling/unmarshaling when appropriate, and rely on expression attribute names and values for any dynamic content.

Secure approach for a query by userID:

import (
    "context"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
    "github.com/labstack/echo/v4"
)

type UserInput struct {
    UserID string `json:"userID" queryparam:"userID"`
}

func GetUserProfile(c echo.Context) error {
    var input UserInput
    if err := c.Bind(&input); err != nil {
        return c.String(400, "invalid input")
    }
    svc := dynamodb.NewFromConfig(awsConfig)
    key := map[string]types.AttributeValue{
        "userID": &types.AttributeValueMemberS{Value: input.UserID},
    }
    req := svc.Query(context.TODO(), &dynamodb.QueryInput{
        TableName:              aws.String("Users"),
        KeyConditionExpression: aws.String("userID = :uid"),
        ExpressionAttributeValues: map[string]types.AttributeValue{
            ":uid": &types.AttributeValueMemberS{Value: input.UserID},
        },
    })
    if req.Err != nil {
        return c.String(500, req.Err.Error())
    }
    // process items
    return c.JSON(200, req.Items)
}

This uses a parameterized expression with placeholders (e.g., :uid) and supplies values via ExpressionAttributeValues, ensuring user input is never interpreted as expression syntax. For scans or filters, apply the same pattern with FilterExpression and ExpressionAttributeValues.

When filtering on dynamic attribute names (rare but possible), use expression attribute names:

expr := "#status = :statusVal"
names := map[string]string{
    "#status": "status",
}
vals := map[string]types.AttributeValue{
    ":statusVal": &types.AttributeValueMemberS{Value: "active"},
}
req := svc.Scan(context.TODO(), &dynamodb.ScanInput{
    TableName:         aws.String("Users"),
    FilterExpression:  aws.String(expr),
    ExpressionAttributeNames:  names,
    ExpressionAttributeValues: vals,
})

By combining SDK expression APIs with strict input validation and avoiding string concatenation, Echo Go services can effectively neutralize NoSQL injection risks. middleBrick’s checks for Input Validation and BOLA/IDOR will confirm whether expressions are safely parameterized in unauthenticated scans.