Path Traversal in Actix with Hmac Signatures

To mitigate Path Traversal when using Hmac Signatures in Actix, the primary rule is to treat the path parameter as untrusted data and to resolve it against an absolute base directory before any filesystem operation. Signature verification should confirm that the client is allowed to request the intended resource, but it must not replace path canonicalization and strict scope enforcement.

First, implement a helper that safely resolves a requested relative path to a location under a fixed base directory. Use Rust’s standard path methods to normalize and check containment, ensuring the final canonical path starts with the base directory. This prevents ../ escapes regardless of what the Hmac signature validates.

Second, keep the Hmac Signature verification but apply it to a canonicalized or normalized path representation, or at least ensure the original path and the signature input are aligned with the same canonical form. This avoids mismatches where an attacker supplies traversal sequences that the client did not explicitly sign, reducing ambiguity in authorization logic.

Below is a concrete, secure Actix handler demonstrating these practices:

use actix_web::{web, HttpResponse};
use hmac::{Hmac, Mac};
use sha2::Sha256;
use std::path::{Path, PathBuf};

type HmacSha256 = Hmac<Sha256>;

const BASE_DIR: &str = "/var/www/public";

fn safe_resolve(base: &str, requested: &str) -> Option<PathBuf> {
    let base_path = Path::new(base).canonicalize().ok()?;
    let mut target = base_path;
    target.push(requested.trim_start_matches('/'));
    target.canonicalize().ok().filter(|p| p.starts_with(&base_path)).map(|p| p.to_path_buf())
}

async fn get_file(
    path: web::Path<String>,
    query: web::Query<std::collections::HashMap<String, String>>
) -> HttpResponse {
    let signature = match query.get("signature") {
        Some(s) => s,
        None => return HttpResponse::BadRequest().body("missing signature"),
    };
    let secret = b"super-secret-key";
    let mut mac = HmacSha256::new_from_slice(secret).expect("HMAC can take key of any size");
    // Optionally use a normalized version of the path for signing/verification
    let normalized = match safe_resolve(BASE_DIR, &path) {
        Some(p) => p,
        None => return HttpResponse::Forbidden().body("invalid path"),
    };
    // If you choose to include the raw path in the signature, ensure it matches what the client intended
    mac.update(path.as_bytes());
    let computed = mac.finalize();
    let result = computed.into_bytes();
    // constant-time comparison would be ideal here
    let computed_hex = hex::encode(result);
    if computed_hex != *signature {
        return HttpResponse::Forbidden().body("invalid signature");
    }
    // Safe to read because safe_resolve enforced containment
    match std::fs::read(&normalized) {
        Ok(bytes) => HttpResponse::Ok().body(bytes),
        Err(_) => HttpResponse::NotFound().body("file not found"),
    }
}

Additional recommendations include using framework utilities or crates that provide path sanitization and preferring Path::join over string concatenation. For production deployments, combine this approach with the middleBrick CLI to scan from terminal with middlebrick scan <url> and verify that your endpoints remain secure against traversal attempts. Teams using CI/CD can add the middleBrick GitHub Action to add API security checks to their pipeline and fail builds if risk scores exceed thresholds, while the Dashboard can help track these scores over time.