Symlink Attack in Flask with Dynamodb

A symlink attack in a Flask application that uses DynamoDB typically arises when the application writes files to a user-influenced location and then registers those files as DynamoDB items, using the file path as a key or attribute. If an attacker can place a symbolic link at that location, they can redirect writes to arbitrary files on the host, and subsequent reads from DynamoDB may reflect attacker-controlled paths or data referenced by those paths. This becomes a server-side or logic bypass issue when the application trusts the stored path and uses it to locate files or resources without canonicalization.

In practice, consider a Flask route that accepts an upload file name, saves it under a configured directory, and stores the path in DynamoDB. If the upload directory is predictable and the application does not resolve symlinks or validate that the saved file is the intended file, an attacker can create a symlink in that directory pointing to a sensitive file such as /etc/passwd. When the application later reads the path from DynamoDB and opens it, the symlink causes unintended file access. The DynamoDB entry itself is benign, but the association between the stored path and the filesystem location enables the abuse.

Another variant occurs when the application uses a key derived from user input to store or retrieve objects from DynamoDB and also uses that key as a filename or symlink target. An attacker who can control the key may create a symlink that changes which file is read or written, effectively bypassing intended access controls. The vulnerability is not in DynamoDB’s data store, but in the file handling logic around how paths are stored, resolved, and used after retrieval from DynamoDB.

The attack surface is expanded when the Flask app runs with elevated privileges or when the DynamoDB item includes metadata used by other services that rely on file paths. Because the scan category BFLA/Privilege Escalation includes path traversal and symlink risks, middleBrick flags these patterns when a stored path can be influenced by unvalidated user input. The presence of DynamoDB does not cause the symlink issue, but it can persist and expose the linkage between attacker-controlled paths and application logic across scans and sessions.

To remediate symlink risks while using DynamoDB in Flask, ensure file paths are fully controlled, resolved, and isolated from user influence. Use absolute base directories, generate safe filenames, and avoid storing or reusing filesystem paths that can be influenced by an attacker. Validate and canonicalize paths before any file operation, and do not rely on values retrieved from DynamoDB as direct filesystem inputs.

Below is a secure example using the AWS SDK for Python (boto3) with Flask. It generates a unique, non-user filename, stores only safe metadata in DynamoDB, and resolves the final path using os.path.realpath before any file operation.

import os
import uuid
from flask import Flask, request
import boto3
from botocore.exceptions import ClientError

app = Flask(__name__)
TABLE_NAME = os.environ.get("DYNAMODB_TABLE", "file_records")
BUCKET_BASE = "/var/uploads"

# Ensure the base directory exists and is not writable via symlinks
os.makedirs(BUCKET_BASE, exist_ok=True)
real_base = os.path.realpath(BUCKET_BASE)

ddb = boto3.resource("dynamodb")
table = ddb.Table(TABLE_NAME)

@app.route("/upload", methods=["POST"])
def upload_file():
    file = request.files.get("file")
    if not file or not file.filename:
        return {"error": "missing file"}, 400

    # Generate a safe filename; do not use the original user filename
    ext = os.path.splitext(file.filename)[1]
    safe_name = f"{uuid.uuid4().hex}{ext}"
    final_path = os.path.realpath(os.path.join(real_base, safe_name))

    # Ensure the resolved path is still within the intended directory
    if not final_path.startswith(real_base):
        return {"error": "invalid path resolution"}, 400

    # Write file using the resolved path
    file.save(final_path)

    # Store only safe metadata in DynamoDB; do not store a mutable path used for filesystem access
    table.put_item(
        Item={
            "id": str(uuid.uuid4()),
            "original_name": file.filename,
            "stored_name": safe_name,
            "base": real_base,
        }
    )
    return {"id": "ok"}, 201

@app.route("/files/<stored_name>", methods=["GET"])
def get_file(stored_name):
    try:
        resp = table.get_item(Key={"stored_name": stored_name})
        item = resp.get("Item")
        if not item:
            return {"error": "not found"}, 404
        final_path = os.path.realpath(os.path.join(item["base"], item["stored_name"]))
        if not final_path.startswith(item["base"]):
            return {"error": "invalid path"}, 400
        if not os.path.isfile(final_path):
            return {"error": "file missing"}, 404
        with open(final_path, "rb") as f:
            data = f.read()
        return data, 200, {"Content-Type": "application/octet-stream"}
    except ClientError as e:
        return {"error": str(e)}, 500

Key practices demonstrated:

• Generate filenames server-side to avoid symlink-prone user input.
• Resolve and validate base directory with os.path.realpath once at startup and reuse it.
• Store only safe, non-actionable values in DynamoDB (e.g., generated filename, base path); do not store mutable paths that are later used directly in filesystem operations.
• Re-validate on retrieval: recompute the absolute path and ensure it remains within the intended base before opening the file.
• Isolate DynamoDB metadata from filesystem decisions; treat DynamoDB as a store for metadata, not as a source of filesystem paths to open without validation.

If your workflow must reference user-provided names, map them to server-generated identifiers and keep the mapping in DynamoDB without using the original name as a filesystem key. This approach reduces the risk that a symlink placed in the upload area can influence which files are read or written, aligning with BFLA/Privilege Escalation guidance from middleBrick’s checks.