Xpath Injection in Actix with Basic Auth

Xpath Injection occurs when user-controlled data is concatenated into an XPath expression without proper escaping or parameterization, allowing an attacker to alter the query’s logic. In Actix web applications that rely on XML payloads and XPath evaluation, this typically manifests through endpoints that parse authenticated requests using XPath against XML documents or configuration files.

When Basic Authentication is used, the username and password are transmitted in the Authorization header as a base64-encoded string. While Basic Auth itself does not cause injection, it can contribute to a vulnerable chain: it often indicates an authenticated or semi-authenticated context where XML processing occurs, and the credentials may be reflected in logs, error messages, or used to select user-specific XML resources. If the application builds XPath expressions by interpolating headers, path parameters, or body content (e.g., selecting a user node by username), an attacker who can observe or influence the authentication context may inject XPath syntax such as or or wildcard predicates to bypass authorization checks or retrieve other user data.

For example, consider an Actix handler that retrieves an XML user store and authenticates via XPath using the provided username directly. A crafted input like admin' or '1'='1 can change the predicate logic, potentially returning multiple nodes or the first node regardless of password. Because the scan methodology includes Authentication and BOLA/IDOR checks, unauthenticated or weakly authenticated XPath endpoints can be detected for excessive agency or improper authorization. The combination of XML-based authentication logic and unescaped input creates an attack surface that can lead to privilege escalation or information disclosure, which are surfaced in the scanner’s findings with severity and remediation guidance.

To prevent Xpath Injection in Actix when using Basic Auth, avoid building XPath expressions through string concatenation. Instead, use parameterized XPath APIs or structured XML queries that treat user input as data, not executable expression. Below are concrete, secure patterns and code examples for Actix.

1. Avoid XPath string interpolation

Do not construct XPath like this:

let username = ...; // user-controlled
let xpath = format!("/users/user[name='{}']", username); // vulnerable

An attacker can supply admin' or '1'='1 and change the query semantics.

2. Use safe XPath parameterization (roxmltree example)

Use a library that supports variable binding or compile-time path construction. With roxmltree, filter nodes in Rust instead of injecting into the path:

use roxmltree::Document;

fn find_user(xml_data: &str, target_user: &str) -> Option<roxmltree::Node> {
    let doc = Document::parse(xml_data).ok()?;
    doc.root()
        .children()
        .find(|n| n.has_tag_name("user") && n.attribute("name") == Some(target_user))
}

// Actix handler example
async fn login_user(body: String, credentials: web::ReqData) -> impl Responder {
    let user = find_user(&body, credentials.user_id());
    match user {
        Some(u) if validate_password(u, credentials.password()) => HttpResponse::Ok().finish(),
        _ => HttpResponse::Unauthorized().finish(),
    }
}

This approach ensures user input is compared as a string value rather than embedded in the XPath, neutralizing injection.

3. Use a dedicated XML library with compiled queries if available

If your XML processing library supports compiled queries or variable substitution, use it. Conceptually:

// Pseudo-code: prefer APIs that accept variables
let query = compile_xpath("//user[@name=$username]");
let result = query.execute_with_vars(params! { "username" => safe_username });

For Actix services that must process XML, prefer deserialization (e.g., serde-xml-rs) to navigate structures without XPath, or use XPath libraries that enforce strict parameterization.

4. Secure Basic Auth handling in Actix

Always use HTTPS to protect credentials in transit. Validate and normalize the username before using it in any selection logic, and avoid logging raw credentials. Here is a minimal, secure Actix handler that extracts Basic Auth safely and avoids XPath injection:

use actix_web::{web, HttpResponse, HttpRequest};
use actix_http::header::HeaderValue;
use base64::prelude::*;

async fn authenticated_endpoint(
    req: HttpRequest,
    body: String,
) -> HttpResponse {
    // Extract and decode Basic Auth header
    let auth_header = match req.headers().get("authorization") {
        Some(h) => h.to_str().unwrap_or(""),
        None => return HttpResponse::Unauthorized().body("missing auth"),
    };
    if !auth_header.starts_with("Basic ") {
        return HttpResponse::Unauthorized().body("invalid auth type");
    }
    let encoded = auth_header.trim_start_matches("Basic ").trim();
    let decoded = match BASE64_STANDARD.decode(encoded.as_bytes()) {
        Ok(d) => d,
        Err(_) => return HttpResponse::Unauthorized().body("invalid encoding"),
    };
    let creds = match String::from_utf8(decoded) {
        Ok(s) => s,
        Err(_) => return HttpResponse::Unauthorized().body("invalid credentials"),
    };
    let parts: Vec<&str> = creds.splitn(2, ':').collect();
    if parts.len() != 2 {
        return HttpResponse::Unauthorized().body("invalid format");
    }
    let (username, password) = (parts[0], parts[1]);

    // Safe processing: avoid XPath injection by not interpolating username into XPath
    // Prefer structured parsing or parameterized queries as shown above
    HttpResponse::Ok().body("auth processed securely")
}

By combining secure credential handling with safe XML querying, you reduce the risk of Xpath Injection and ensure that authentication logic remains robust.