Symlink Attack in Actix with Jwt Tokens

A symlink attack in an Actix service that uses JWT tokens for authentication can occur when file system operations intersect with token validation or token handling code. In this context, the vulnerability arises not from JWT itself, but from how the application resolves file paths when storing or retrieving data associated with a JWT, such as user-specific claims, uploaded artifacts, or cached key material.

Consider an endpoint that accepts a user identifier from a validated JWT claim and uses it to build a filesystem path, for example to read a user configuration or store uploaded files. If the application directly concatenates the user-supplied or token-derived identifier into a path and resolves it without canonicalization or restriction, an attacker who can influence the identifier (for example, via a compromised or forged token, or via a trusted upstream service) may provide path traversal sequences or symbolic link components. When the Actix service resolves this path, it may follow a symlink that points outside the intended directory, leading to unauthorized read or overwrite of files that should not be accessible through the API.

This becomes a security-relevant issue in the context of JWT tokens because tokens may carry user identifiers, roles, or other claims that the application uses to derive filesystem locations. If token validation is correctly performed but path resolution is weak, an attacker with a valid token (stolen or obtained via other means) can still exploit path manipulation to traverse directories or follow symlinks. In other words, the combination is not that JWT introduces the symlink risk, but that token-derived inputs used in file paths can lead to insecure resolution patterns that symlink attacks leverage.

For example, an Actix handler might decode a JWT to obtain a sub claim and then use it to form a path like /data/users/{sub}/config.yaml. If the application does not canonicalize this path and an attacker can control or influence the sub claim (through a compromised token or a trusted integration), they might supply a value such as ../../../etc/passwd or a directory containing a symlink that resolves to sensitive system files. The handler may read or write data unintentionally, exposing or modifying files outside the application’s intended scope. This pattern maps to authorization issues similar to BOLA/IDOR, where access control is bypassed via path manipulation rather than direct ID tampering.

Because middleBrick tests unauthenticated attack surfaces and includes checks such as Property Authorization and Input Validation alongside SSRF and Inventory Management, it can surface indicators that user-controlled inputs (including those derived from JWT claims) lead to unsafe file system interactions. Findings will highlight insecure path construction and lack of canonicalization, with remediation guidance focused on input validation and safe path handling rather than changing the JWT mechanism itself.

To mitigate symlink risks when using JWT tokens in Actix, focus on strict input validation, canonical path resolution, and scoping file operations to a controlled base directory. Do not rely on token claims alone to determine file paths; instead, map claims to safe internal identifiers and enforce strict path constraints.

Below are concrete, realistic code examples in Rust using Actix and the jsonwebtoken crate, demonstrating secure handling of JWT-derived identifiers when interacting with the file system.

use actix_web::{web, HttpResponse, Result};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use std::fs;
use std::path::{Path, PathBuf};

const BASE_DIR: &str = "/safe/app/data/users";

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    // other claims
}

fn validate_token(token: &str) -> Result<Claims, jsonwebtoken::errors::Error> {
    let decoding_key = DecodingKey::from_secret(&[0u8; 32]);
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;
    decode::<Claims>(token, &decoding_key, &validation)
        .map(|token_data| token_data.claims)
}

fn safe_user_path(claims_sub: &str) -> PathBuf {
    // Normalize and restrict to BASE_DIR to prevent directory traversal
    let user_id = sanitize_user_id(claims_sub);
    let mut path = PathBuf::from(BASE_DIR);
    path.push(user_id);
    path
}

fn sanitize_user_id(input: &str) -> String {
    // Allow only alphanumeric and safe characters; reject path separators and ".."
    input.chars().filter(|c| c.is_alphanumeric() || *c == '-' || *c == '_').collect()
}

async fn get_user_config(token: String) -> Result<HttpResponse> {
    let claims = validate_token(&token).map_err(|e| {
        actix_web::error::ErrorUnauthorized(format!("Invalid token: {:?}", e))
    })?;

    let base = Path::new(BASE_DIR);
    if !base.exists() {
        fs::create_dir_all(base).expect("Failed to create base directory");
    }

    let user_path = safe_user_path(&claims.sub);
    // Ensure the resolved path is within BASE_DIR
    let canonical_base = base.canonicalize().expect("Base directory must be canonical");
    let canonical_user = user_path.canonicalize()
        .unwrap_or_else(|_| user_path.clone()); // fallback if file does not exist yet

    if !canonical_user.starts_with(canonical_base) {
        return Err(actix_web::error::ErrorForbidden("Path traversal detected"));
    }

    let config_content = fs::read_to_string(canonical_user)
        .unwrap_or_else(|_| "{}".to_string());

    Ok(HttpResponse::Ok().body(config_content))
}

Key points in this approach:

• Validate and decode the JWT early, and treat the sub claim as an opaque identifier rather than a filesystem path component.
• Sanitize the identifier to allow only safe characters and reject any characters that could enable directory traversal or symlink resolution.
• Construct paths by appending the sanitized identifier to a strict base directory, and always canonicalize both the base and the target path.
• Verify that the canonical target path starts with the canonical base path before performing any file operations; this prevents resolution through symlinks that escape the base directory.
• Do not follow symlinks when reading or writing files; if your runtime must handle symlinks, explicitly resolve and validate them against the base directory.

These steps ensure that JWT-derived inputs cannot be used to escape intended boundaries, mitigating symlink-based attacks while preserving the utility of token-based authentication.