Symlink Attack in Aspnet with Bearer Tokens

A Symlink Attack in an ASP.NET API context with Bearer Tokens occurs when an authenticated endpoint handles file paths or user-supplied references insecurely, enabling an attacker to redirect file operations outside the intended directory. Because the endpoint validates the Bearer Token for access but does not validate or sanitize path inputs, an authenticated request can traverse directories using symbolic links (symlinks), potentially reading, overwriting, or deleting files owned by the application or other users. This combines authentication via Bearer Tokens with path traversal and insecure file handling to escalate the impact of a seemingly limited access scenario.

For example, an API might accept a file identifier, resolve it to a physical path on disk, and serve or process it. If the API does not canonicalize the resolved path and remove symlink components, a malicious authenticated user (or a compromised token) can supply a path like ../../../etc/passwd or a symlink such as /tmp/uploads/link -> /etc. The application then follows the symlink and exposes sensitive system files. Because the request includes a valid Bearer Token, the operation appears authorized, making the attack harder to detect through simple access logging alone.

In the context of the 12 security checks run by middleBrick, this pattern maps to BOLA/IDOR and Property Authorization checks, where access control must be evaluated not just at the authentication layer, but also at the business logic and file system interaction layers. An API that issues Bearer Tokens but fails to validate path intent and file system boundaries may expose sensitive configuration files, logs, or application data. Attackers can also chain symlink creation with write endpoints to plant malicious content that the application later serves, leading to further compromise. Detection requires correlating authenticated requests with file operation inputs and verifying that resolved paths remain within the intended scope.

Using OpenAPI/Swagger analysis, middleBrick can highlight endpoints that accept path parameters or file references while also requiring Bearer Tokens, and cross-reference these with runtime findings to identify missing path canonicalization and authorization checks. This helps teams understand how authenticated access can be misused when file handling logic does not account for symlink-based redirection.

Remediation focuses on ensuring that Bearer Token authentication is complemented by strict path validation, canonicalization, and scope enforcement. Never trust user input for file paths, even when a valid token is present. Use platform utilities to resolve full paths and confirm they remain within an allowed directory tree. Below is a concrete example of secure file access in ASP.NET Core that combines Bearer Token usage with safe path handling.

using System;
using System.IO;
using System.Security.Principal;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/files")]
public class FilesController : ControllerBase
{
    private readonly string _baseDirectory;

    public FilesController()
    {
        // Define a strict base directory for all file operations
        _baseDirectory = Path.GetFullPath(Path.Combine(Directory.GetCurrentDirectory(), "App_Data"));
        if (!Directory.Exists(_baseDirectory))
        {
            Directory.CreateDirectory(_baseDirectory);
        }
    }

    [HttpGet("{fileId}")]
    [Authorize(AuthenticationSchemes = "Bearer")]
    public IActionResult GetFile(string fileId)
    {
        if (string.IsNullOrWhiteSpace(fileId))
        {
            return BadRequest("File identifier is required.");
        }

        // Normalize input: allow only alphanumeric, underscores, and hyphens
        if (!System.Text.RegularExpressions.Regex.IsMatch(fileId, @"^[a-zA-Z0-9_-]+$"))
        {
            return BadRequest("Invalid file identifier.");
        }

        // Build the full path and canonicalize
        string requestedPath = Path.GetFullPath(Path.Combine(_baseDirectory, fileId));

        // Ensure the resolved path is within the allowed base directory
        if (!requestedPath.StartsWith(_baseDirectory, StringComparison.OrdinalIgnoreCase))
        {
            return Forbid();
        }

        if (!System.IO.File.Exists(requestedPath))
        {
            return NotFound();
        }

        byte[] data = System.IO.File.ReadAllBytes(requestedPath);
        return File(data, "application/octet-stream");
    }
}

Key points in this remediation:

• Authentication is enforced via Bearer Tokens using [Authorize(AuthenticationSchemes = "Bearer")], ensuring only authenticated requests proceed.
• Input validation restricts fileId to a safe character set, reducing path traversal and injection risks.
• Path.GetFullPath canonicalizes the path to eliminate ., .., and symlink components.
• A strict scope check confirms the resolved path starts with the application-controlled base directory, preventing symlink-based escapes.

For APIs that must reference files by external identifiers, maintain a mapping (e.g., a database) between identifiers and safe storage locations rather than concatenating user input into paths. Additionally, audit and restrict file system permissions for the application runtime to minimize the impact of any successful path traversal. middleBrick can surface endpoints that accept Bearer Tokens alongside path parameters and highlight missing canonicalization through its OpenAPI/Swagger and runtime checks, helping teams prioritize fixes.