Symlink Attack in Aspnet with Mutual Tls

A symlink attack in an ASP.NET application occurs when an attacker tricks the server into reading or writing files through symbolic links, often leveraging file path manipulation or insecure file handling. When mutual TLS (mTLS) is enforced, the transport layer is strongly authenticated and encrypted, which prevents on-path tampering of HTTP traffic. However, mTLS does not reduce risks in the application logic or file system interactions. The presence of mTLS can create a false sense of security, leading developers to assume that all inbound requests are trusted once the client certificate is validated.

In this context, the vulnerability arises when the ASP.NET application processes uploaded files, resolves paths, or writes logs based on user-controlled input without canonicalization. For example, an endpoint that accepts a filename in a request might join it with a base directory using Path.Combine but fail to resolve symbolic links. If the application runs with elevated permissions, an authenticated client (presenting a valid client certificate) could supply a crafted path such as ../../../secret.txt or a symlink that points to a sensitive system file. Because mTLS ensures the request is authenticated, the application may skip additional authorization checks, inadvertently allowing file access or overwrites that lead to information disclosure or privilege escalation.

Consider a scenario where an ASP.NET Core API uses mTLS and exposes an endpoint to retrieve user documents. The code might resolve the document path as follows:

var basePath = Path.Combine(Directory.GetCurrentDirectory(), "user_docs");
var userFile = Path.GetFullPath(Path.Combine(basePath, userSuppliedFileName));

If userSuppliedFileName includes sequences like ../../ or a symlink within the filesystem that points outside user_docs, the resolved path can escape the intended directory. An attacker with a valid client certificate can repeatedly probe the endpoint to locate or overwrite files, leveraging mTLS for access while the application fails to validate that the resolved path remains within the allowed directory tree.

Moreover, log files or temporary artifacts created by the application may themselves become targets if they contain sensitive data or if symlinks are placed in writable locations. Since mTLS secures the channel, the attack surface shifts to file system permissions and path handling, areas not protected by transport-layer security. The combination of strong client authentication and insufficient path validation increases the likelihood of successful exploitation because developers may neglect to apply the same rigor to file operations as they do to network configuration.

Remediation focuses on strict path validation and avoiding reliance on mTLS for application-level authorization. Always resolve and canonicalize file paths, and ensure that user input cannot escape intended directories. Below are concrete code examples for ASP.NET Core that demonstrate secure handling when mTLS is in use.

1. Use Path.GetFullPath and compare the normalized result against the allowed base directory:

var basePath = Path.GetFullPath(Path.Combine(Directory.GetCurrentDirectory(), "user_docs"));
var fullPath = Path.GetFullPath(Path.Combine(basePath, userSuppliedFileName));

if (!fullPath.StartsWith(basePath, StringComparison.OrdinalIgnoreCase))
{
    throw new SecurityException("Invalid path");
}

2. Resolve symlinks explicitly with Path.Resolve (available in .NET 6+) to ensure the final target is within the permitted directory:

var basePath = Path.GetFullPath(Path.Combine(Directory.GetCurrentDirectory(), "user_docs"));
var fullPath = Path.GetFullPath(Path.Combine(basePath, userSuppliedFileName)).Resolve();
var baseFullPath = new DirectoryInfo(basePath).FullName.Resolve();

if (!fullPath.StartsWith(baseFullPath, StringComparison.OrdinalIgnoreCase))
{
    throw new SecurityException("Path traversal detected");
}

3. When using minimal APIs, validate the path before any file operation and avoid concatenating raw user input:

app.MapGet("/documents/{fileName}", (string fileName, IWebHostEnvironment env) =>
{
    var basePath = Path.GetFullPath(Path.Combine(env.ContentRootPath, "user_docs"));
    var fullPath = Path.GetFullPath(Path.Combine(basePath, fileName)).Resolve();

    if (!fullPath.StartsWith(basePath, StringComparison.OrdinalIgnoreCase))
    {
        return Results.Forbid();
    }

    if (!File.Exists(fullPath))
    {
        return Results.NotFound();
    }

    var content = File.ReadAllText(fullPath);
    return Results.Content(content, "text/plain");
});

4. Enforce mTLS at the server level but do not skip authorization logic. In Program.cs, require client certificates and still apply route and file ownership checks:

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ConfigureHttpsDefaults(httpsOptions =>
    {
        httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
    });
});
// Additional authorization policies can be added here, but file validation remains mandatory.

5. For file uploads, store files with server-generated names and maintain a mapping in a database, avoiding direct use of client-supplied filenames:

var safeFileName = Guid.NewGuid().ToString() + Path.GetExtension(userSuppliedFileName);
var fullPath = Path.Combine(basePath, safeFileName);
await using var stream = new FileStream(fullPath, FileMode.Create);
await uploadStream.CopyToAsync(stream);

These practices ensure that even with mTLS providing strong client authentication, the application remains resilient against symlink-based attacks by controlling how paths are constructed and validated.