Http Request Smuggling in Actix with Basic Auth

HTTP Request Smuggling leverages discrepancies in how a frontend proxy and an origin server interpret message boundaries, often involving Content-Length versus Transfer-Encoding headers. In Actix applications that use HTTP Basic Authentication, the combination of parsing logic and authentication handling can amplify the risk if requests are forwarded through intermediaries such as load balancers or API gateways.

Actix Web is a robust Rust framework, but when it receives requests that contain both an Authorization header (Basic Auth) and ambiguous or conflicting size indicators, two issues can arise:

• Request splitting: an attacker may inject an extra request into the stream by carefully crafting headers and body delimiters. If the frontend does not normalize or reject ambiguous encodings before passing traffic to Actix, the backend may process one request while the proxy believes another request was handled.
• Request hiding: a request may be entirely hidden from Actix if the proxy interprets the message boundary differently and consumes part of the stream, causing Actix to process only a subset of the intended operations. This is particularly sensitive when Basic Auth credentials are present, because an authenticated session may be reused across requests with different interpretations of the same stream.

Basic Auth itself does not cause smuggling, but its presence highlights header parsing issues. Since the Authorization header is static in format (Base64-encoded credentials), it can be part of the header block used to determine message boundaries. If a request includes both Transfer-Encoding: chunked and Content-Length, and Actix is behind a misconfigured proxy, the framework may parse one request while the proxy forwards or caches another. This can lead to authentication bypass scenarios where a request lacking proper credentials is smuggled inside an authenticated request, or where an authenticated request is split, causing credentials to apply inconsistently.

In practice, an attacker might send a request such as:

POST /api/resource HTTP/1.1
Host: example.com
Content-Length: 38
Transfer-Encoding: chunked
Authorization: Basic dXNlcjpwYXNz

0

GET /admin/secret HTTP/1.1
Host: example.com
Content-Length: 0

If Actix is behind a proxy that prioritizes Transfer-Encoding while the origin enforces Content-Length, the first request body may be interpreted as chunked data, and the second request may be processed separately by Actix, potentially without the required authentication. This illustrates why consistent normalization at the edge is critical when Basic Auth is in use.

middleBrick scans include checks for BOLA/IDOR and related authorization issues, which can surface inconsistent handling of authentication headers across request boundaries. By correlating runtime behavior with OpenAPI specifications and runtime findings, such scans help identify whether authorization headers are being interpreted differently across layers, a common precursor to smuggling risks.

Remediation focuses on preventing header ambiguity and ensuring consistent parsing. In Actix, you should enforce strict header handling, reject requests that mix Content-Length and Transfer-Encoding, and validate the Authorization header early in the pipeline.

Example: Reject ambiguous requests before routing to business logic.

use actix_web::{web, App, HttpRequest, HttpServer, Responder, middleware, http::header};
use actix_web::error::ErrorBadRequest;

async fn validate_headers(req: HttpRequest) -> Result<(), actix_web::Error> {
    let has_content_length = req.headers().get(header::CONTENT_LENGTH).is_some();
    let has_transfer_encoding = req.headers().get(header::TRANSFER_ENCODING).is_some();

    if has_content_length && has_transfer_encoding {
        return Err(ErrorBadRequest("Conflicting headers: Content-Length and Transfer-Encoding"));
    }
    Ok(())
}

async fn index(req: HttpRequest, body: web::Bytes) -> impl Responder {
    // Authentication check
    let auth_header = req.headers().get(header::AUTHORIZATION)
        .and_then(|h| h.to_str().ok())
        .unwrap_or("");
    if !auth_header.starts_with("Basic ") {
        return Err(ErrorBadRequest("Missing or invalid Authorization header"));
    }
    // Proceed with request handling
    format!("Received {} bytes", body.len())
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .wrap(middleware::Logger::default())
            .route("/api/resource", web::post().to(validate_headers))
            .route("/api/resource", web::post().to(index))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

Example: Enforce strict Content-Length parsing and normalize credentials handling.

use actix_web::web;
use actix_web::http::header;
use actix_web::HttpRequest;

fn extract_credentials(req: &HttpRequest) -> Option {
    req.headers()
        .get(header::AUTHORIZATION)
        .and_then(|v| v.to_str().ok())
        .filter(|s| s.starts_with("Basic "))
        .map(|s| s.to_string())
}

async fn handle_secure(data: web::Json, req: HttpRequest) -> &'static str {
    let creds = extract_credentials(&req).unwrap_or_default();
    if creds.is_empty() {
        return "Unauthorized";
    }
    // Process request
    "OK"
}

Operational practices:

• Place a normalization layer (API gateway or load balancer) that removes or rejects requests mixing Content-Length and Transfer-Encoding before they reach Actix.
• Use middleware to log and monitor Authorization header presence and format anomalies.
• Apply consistent authentication checks early, ensuring that routing decisions are made only after header validation.

These steps reduce the attack surface for smuggling by ensuring that message boundaries are interpreted identically across all layers, which complements continuous scanning with tools like middleBrick that map findings to frameworks such as OWASP API Top 10 and can surface inconsistencies in authentication header handling.