Symlink Attack in Aspnet with Dynamodb

A symlink attack in an ASP.NET application that uses Amazon DynamoDB typically occurs when the application writes user-influenced files to a location that is later referenced by DynamoDB-stored metadata or configuration. If an attacker can control the filename or path and the application resolves those values to files on disk, they may replace a legitimate file with a symbolic link. When the application or a privileged process later reads or writes the file through the symlink, the attacker can redirect writes to sensitive locations or cause the application to operate on arbitrary files. In a DynamoDB context, this often maps to how the application stores and later uses object keys, file paths, or endpoint configurations retrieved from DynamoDB.

Consider an ASP.NET service that allows users to upload profile images. The service stores the image on disk at a path derived from a user ID and a server-supplied filename, while metadata (including the relative path to the image) is persisted in DynamoDB. If the application does not sanitize the user-controlled filename and uses predictable paths, an authenticated user can craft a filename such as ../../../etc/passwd or a filename that resolves to a symlink. The application writes the file, records the path in a DynamoDB item, and later another process (or the same process with higher privileges) reads the path from DynamoDB and opens the file. Because the file is a symlink, the read opens the target file, potentially exposing sensitive system files. Conversely, a write operation triggered later (e.g., an avatar update) can overwrite critical files through the symlink.

The DynamoDB component does not execute code or directly follow symlinks; the risk arises from the application layer’s misuse of data retrieved from DynamoDB. For example, if the application stores a key like user/123/avatar.png and later constructs a filesystem path by concatenating a base directory with that key without canonicalization, an attacker who can control the key (perhaps via account takeover or insufficient validation) can manipulate the stored key to point to a symlink. An attacker might also exploit insecure temporary file creation or predictable filenames in workflows that involve DynamoDB Streams or export jobs, where exported files are later processed based on metadata stored in DynamoDB.

In the AWS ecosystem, DynamoDB is a managed NoSQL store and does not provide filesystem semantics such as symlink resolution. The vulnerability is therefore an ASP.NET and application logic issue, but DynamoDB becomes a persistence and configuration vector: the database reliably stores the attacker-influenced path or key, ensuring that the malicious symlink is used across restarts and deployments. Common root causes include missing path canonicalization, insecure use of user input in filenames, and insufficient separation between data stored in DynamoDB and filesystem operations. Because the scan category for these issues falls under Input Validation and Property Authorization, middleBrick flags findings here to highlight the interplay between storage metadata and filesystem behavior.

Remediation focuses on ensuring that data stored in DynamoDB and used by ASP.NET never directly controls filesystem paths and that all path construction is canonicalized and validated. Do not trust keys or metadata from DynamoDB to determine filesystem locations without strict validation.

1. Validate and sanitize user input before using it in filenames or paths

Never use raw user input to build filesystem paths. Use a whitelist of allowed characters and generate safe filenames on the server.

using System;
using System.IO;
using Amazon.DynamoDBv2.DataModel;

public class ProfileService
{
    private readonly string _baseUploadDir = Path.Combine(Directory.GetCurrentDirectory(), "uploads");

    public string SaveProfileImage(string userId, IFormFile file)
    {
        // Generate a safe, unique filename on the server
        var safeFileName = $"{Guid.NewGuid()}{Path.GetExtension(AllowedExtensions(file.FileName))}";
        var userDir = Path.Combine(_baseUploadDir, userId);
        Directory.CreateDirectory(userDir);
        var filePath = Path.Combine(userDir, safeFileName);

        using (var stream = new FileStream(filePath, FileMode.Create))
        {
            file.CopyTo(stream);
        }

        // Store only the logical reference in DynamoDB, not the raw user input
        var key = $"user/{userId}/images/{safeFileName}";
        return key;
    }

    private string AllowedExtensions(string fileName)
    {
        var ext = Path.GetExtension(fileName).ToLowerInvariant();
        return ext switch
        {
            ".png" or ".jpg" or ".jpeg" or ".gif" => ext,
            _ => throw new ArgumentException("Invalid file extension")
        };
    }
}

2. Canonicalize and validate paths when reading files referenced by DynamoDB

When retrieving a path or key from DynamoDB and using it to access the filesystem, resolve and validate it against an allowed base directory to prevent traversal or symlink-based escapes.

using System;
using System.IO;
using Amazon.DynamoDBv2.DataModel;

public class FileService
{
    private readonly string _baseDirectory = Path.GetFullPath(@"C:\app\data");

    public byte[] ReadFileByKey(string keyFromDynamoDb)
    {
        // Build the candidate path
        var candidate = Path.GetFullPath(Path.Combine(_baseDirectory, keyFromDynamoDb.Replace("..", string.Empty)));

        // Ensure the resolved path is within the allowed base directory
        if (!candidate.StartsWith(_baseDirectory, StringComparison.OrdinalIgnoreCase))
        {
            throw new UnauthorizedAccessException("Path traversal attempt detected.");
        }

        // Additional check: ensure the target is a file and not a symlink to a sensitive location
        var fileInfo = new FileInfo(candidate);
        if (!fileInfo.Exists || fileInfo.Attributes.HasFlag(FileAttributes.ReparsePoint))
        {
            throw new FileNotFoundException("File not found or is a reparse point.");
        }

        return File.ReadAllBytes(candidate);
    }
}

3. Use DynamoDB for metadata only; store files in isolated storage with access control

Keep sensitive configuration and user-provided paths in DynamoDB as opaque references. Store actual files in a location not directly keyed by user-controlled values, and apply strict ACLs. When scanning with middleBrick, findings related to Input Validation and Property Authorization will highlight insecure usage patterns that could enable symlink attacks in ASP.NET apps that integrate with DynamoDB.

4. Secure temporary file and export workflows

If your ASP.NET integration exports data to files for processing (e.g., via DynamoDB Streams or backups), ensure temporary files use secure APIs that do not follow symlinks. Use Path.GetTempFileName and set appropriate file permissions. Do not construct temporary paths by concatenating user-supplied values retrieved from DynamoDB.

5. Continuous monitoring via the Pro plan

For ongoing protection, use the middleBrick Pro plan to enable continuous monitoring of your API and application endpoints. This helps detect regressions or new attack vectors that could reintroduce symlink risks in the interaction between ASP.NET and DynamoDB workflows. The dashboard tracks security scores over time and integrates with GitHub Actions to fail builds if risk thresholds are exceeded.