Symlink Attack in Actix with Dynamodb

A symlink attack in an Actix service that uses DynamoDB typically occurs when the application builds file paths from user-controlled input and writes or reads files on the host filesystem. If those paths are not strictly validated, an attacker can provide a filename such as ../../../../etc/passwd or a specially crafted name that resolves through symbolic links to a sensitive location. Because Actix is a Rust web framework, developers often integrate DynamoDB for persistence via the AWS SDK for Rust. In this setup, the application might log request metadata or store user-supplied identifiers as files on disk, for example to cache responses or upload user artifacts. If the constructed file path traverses directories and points to a location outside the intended directory tree, an attacker can read arbitrary files or overwrite configuration or credential files that the process can access.

When DynamoDB is involved, the exposure vector is usually indirect: the application writes a file whose name is derived from a DynamoDB attribute (such as a user ID or a key name) or uses a filename obtained from a DynamoDB record. If the attribute is attacker-controlled (for example, a username or key name that an authenticated user can set), an adversary can inject path traversal or symlink sequences. At runtime, when the Actix handler writes the file to disk, the symlink redirects the write to a sensitive path. Similarly, reading from DynamoDB may supply a filename that the server later opens without canonicalization, enabling disclosure of arbitrary files if the stored name was maliciously crafted earlier. The combination therefore involves DynamoDB as a data store for attacker-influenced identifiers and Actix as the runtime that resolves these identifiers into filesystem operations, creating a path-based security boundary violation.

An example scenario: an Actix endpoint accepts a file_key parameter, retrieves an object from DynamoDB that contains a stored_name field, and opens a file under /var/app/uploads/ using that name. If the stored_name is set to ../../../etc/hosts by an attacker who can write to DynamoDB or trick the system into storing malicious metadata, the file open resolves outside the intended directory. Even without direct DynamoDB write access, insufficient validation of filenames used in logging or caching can allow symlink races where an attacker creates a symlink in the upload directory that points to a protected resource, and the Actix service follows it on the next read or write. This illustrates how DynamoDB-supplied metadata combined with unsafe path handling in Actix can expose sensitive data or enable overwrite conditions.

To remediate symlink risks in an Actix service integrated with DynamoDB, enforce strict path validation and avoid any direct use of DynamoDB-supplied identifiers in filesystem operations. Use canonicalization and strict prefix checks, and prefer generating your own safe filenames rather than trusting external data. Below are concrete, safe patterns in Rust using the official AWS SDK for Rust and Actix web.

1. Safe file path construction with prefix enforcement

Always resolve paths against a base directory and ensure the final path remains inside that directory. Use std::fs::canonicalize on the base directory and compare prefixes before opening files.

use std::path::{Path, PathBuf};
use std::fs;

fn safe_path(base: &Path, requested: &str) -> std::io::Result<PathBuf> {
    let base = fs::canonicalize(base)?;
    let mut target = base.clone();
    target.push(requested);
    let target = fs::canonicalize(&target)?;
    if target.starts_with(&base) {
        Ok(target)
    } else {
        Err(std::io::Error::new(std::io::ErrorKind::PermissionDenied, "path escape detected"))
    }
}

// Usage in an Actix handler (pseudocode):
// let path = safe_path(Path::new("/var/app/uploads"), &safe_filename).await?;

2. Generate safe filenames from DynamoDB records

When storing files associated with DynamoDB items, generate filenames on the server side (e.g., UUIDs) and keep the mapping in DynamoDB. Avoid using user-controlled strings as filenames.

use aws_sdk_dynamodb::types::AttributeValue;
use uuid::Uuid;
use std::path::PathBuf;

fn make_safe_filename(record_id: &str) -> PathBuf {
    // record_id could be a DynamoDB primary key; do not use it directly as a filename.
    let ext = match record_id.rsplit('.').next() {
        Some("json") => "json",
        Some("txt") => "txt",
        _ => "bin",
    };
    let name = Uuid::new_v4().to_string();
    PathBuf::from(format!("{}.{}", name, ext))
}

// Example of storing metadata in DynamoDB alongside the safe filename:
// let item = aws_sdk_dynamodb::types::PutItemInputBuilder::new()
//     .table_name("Uploads")
//     .item("user_id", AttributeValue::S(user_id.into()))
//     .item("safe_name", AttributeValue::S(safe_name.to_string_lossy().into()))
//     .item("record_id", AttributeValue::S(record_id.into()))
//     .build();

3. Validate and sanitize before logging or caching

If you must log filenames or cache identifiers retrieved from DynamoDB, sanitize them to remove traversal components and reject names containing sequences like .. or absolute paths.

fn sanitize_filename(filename: &str) -> Option<String> {
    let cleaned = filename
        .split('/')
        .filter(|part| !part.is_empty() && *part != "." && *part != "..")
        .collect::

use actix_web::{dev::Payload, Error, FromRequest, HttpRequest};
use futures::future::{ok, Ready};

struct SafePath(String);

impl FromRequest for SafePath {
    type Error = Error;
    type Future = Ready<Result<Self, Self::Error>>;

    fn from_request(req: &HttpRequest, _: &mut Payload) -> Self::Future {
        let candidate = req.match_info().get("path").unwrap_or_default();
        if candidate.contains("..") || candidate.starts_with('/') {
            return ok(SafePath(String::new())); // will fail downstream
        }
        ok(SafePath(candidate.to_string()))
    }
}