Injection Flaws in Flask with Dynamodb

Injection flaws occur when untrusted data is interpreted as part of a command or query. In a Flask application using Amazon DynamoDB, injection typically manifests through unsafe construction of DynamoDB expressions, especially when building KeyConditionExpression, FilterExpression, or ExpressionAttributeValues from user input. Unlike SQL, DynamoDB does not support a traditional query language, but expression parameters can still be manipulated if values are interpolated into the expression string itself rather than passed as expression attribute values.

Consider a Flask route that retrieves a user item by username and timestamp:

username = request.args.get('username')
timestamp = request.args.get('timestamp')
response = table.query(
    KeyConditionExpression=Key('username').eq(username) & Key('timestamp').eq(timestamp)
)

If username and timestamp are taken directly from the request and used to build expression strings via concatenation or formatting, an attacker can inject crafted values to change query behavior or probe schema. For example, passing username as "foo OR begins_with(#pk, '')" does not cause SQL-style injection, but it can expose how the service handles malformed partition key values and may result in unexpected query results or errors that reveal metadata. More critically, unsafe use of ExpressionAttributeValues with string interpolation can lead to logic manipulation:

# Unsafe: building expression with string formatting
expression = f"username = :uid AND status = :sts"
response = table.scan(FilterExpression=expression, ExpressionAttributeValues={':uid': 'admin', ':sts': 'active'})

Here, if an attacker controls the format of the expression string (for example through a parameter that influences which fields are selected), they might introduce additional conditions or comment-like patterns that affect result sets. DynamoDB does not support comments, but nested conditions and reserved words can be abused when input is not strictly validated.

The twelve parallel security checks in middleBrick exercise these risks by testing unauthentinated attack surfaces, including property authorization and input validation. The scanner examines how expressions and attribute values are composed in runtime interactions and flags patterns where expression components or attribute names appear to be derived from untrusted sources without strict allowlisting. Findings highlight deviations such as missing validation on key attributes, lack of length or pattern checks on string inputs, and inconsistent use of condition builders that may enable privilege escalation or data exposure in adjacent endpoints.

Remediation centers on strict separation of expression structure from data, using DynamoDB’s provided parameterization exclusively. Always use KeyConditionExpression or FilterExpression with placeholders and supply values through ExpressionAttributeValues. Never concatenate or interpolate user input into expression strings.

Safe query using key condition expressions:

from flask import request
from boto3.dynamodb.conditions import Key

@app.route('/user')
def get_user():
    username = request.args.get('username')
    timestamp = request.args.get('timestamp')
    # Validate input types and length before using
    if not isinstance(username, str) or not isinstance(timestamp, str):
        return {'error': 'invalid parameters'}, 400
    response = table.query(
        KeyConditionExpression=Key('username').eq(username) & Key('timestamp').eq(timestamp)
    )
    return {'items': response.get('Items', [])}

Safe scan with expression attribute values:

status = request.args.get('status')
# Validate status against an allowlist
allowed = {'active', 'inactive', 'pending'}
if status not in allowed:
    return {'error': 'invalid status'}, 400
response = table.scan(
    FilterExpression=Attr('status').eq(status),
    ExpressionAttributeValues={}  # Not needed when using Attr() directly with literals
)

When using dynamic attribute names (e.g., for flexible querying), validate attribute names against a known set and use ExpressionAttributeNames:

field = request.args.get('field')
valid_fields = {'created_at', 'updated_at', 'email'}
if field not in valid_fields:
    return {'error': 'invalid field'}, 400
response = table.scan(
    FilterExpression=Attr(field).eq('[email protected]'),
    ExpressionAttributeNames={field: field}
)

middleBrick’s checks for input validation and property authorization highlight misconfigurations where expression builders are constructed from unchecked inputs. By integrating the CLI (middlebrick scan <url>) or the GitHub Action into CI/CD pipelines, teams can automatically fail builds when patterns resembling expression injection are detected, complementing the continuous monitoring available in the Pro plan.