Http Request Smuggling in Actix

Http Request Smuggling occurs when an HTTP server misinterprets the boundaries between HTTP requests, allowing an attacker to hide malicious requests inside legitimate traffic. In Actix, this vulnerability typically manifests through improper handling of Content-Length and Transfer-Encoding headers.

The most common attack pattern in Actix involves sending requests with conflicting Content-Length and Transfer-Encoding headers. When Actix receives a request like:

POST /api/resource HTTP/1.1
Host: example.com
Content-Length: 6
Transfer-Encoding: chunked

0

POST /api/admin HTTP/1.1
Host: example.com
Content-Length: 9

malicious-data

The server may process the first request body as "malicious-data" while the second request gets interpreted as part of the first request. This creates a situation where the attacker's malicious request is hidden within what appears to be a legitimate request.

Actix's default configuration is generally resistant to basic smuggling attempts because it properly validates header combinations. However, vulnerabilities can emerge when:

• Custom middleware modifies or removes Content-Length/Transfer-Encoding headers without proper validation
• Proxies or load balancers in front of Actix have different parsing logic than Actix itself
• Actix applications use chunked transfer encoding without proper boundary validation
• Multiple Content-Length headers are accepted without rejecting the request

A specific Actix pattern that can lead to smuggling involves using the Bytes extractor with chunked encoding:

use actix_web::{web, App, HttpMessage, HttpResponse, HttpServer};

async fn handle_request(mut payload: web::Payload) -> HttpResponse {
    let mut body = web::BytesMut::new();
    
    // If chunked encoding is mishandled here, smuggling becomes possible
    while let Some(chunk) = payload.next().await {
        let chunk = chunk?;
        body.extend_from_slice(&chunk);
    }
    
    // Process body without validating chunk boundaries
    HttpResponse::Ok().finish()
}

The key insight is that Actix itself handles smuggling detection well, but the surrounding infrastructure and custom middleware can create exploitable gaps.

Detecting HTTP Request Smuggling in Actix applications requires a multi-layered approach. The most effective method is using automated security scanning tools that understand Actix's specific request handling patterns.

middleBrick's scanner includes Actix-specific detection capabilities that examine how your application processes HTTP requests. The scanner tests for:

• Conflicting Content-Length and Transfer-Encoding header handling
• Multiple Content-Length header acceptance
• Chunked transfer encoding boundary validation
• Header normalization and canonicalization issues

To scan an Actix application with middleBrick:

# Install the CLI tool
npm install -g middlebrick

# Scan your Actix API endpoint
middlebrick scan https://your-actix-app.com/api

# Or use the GitHub Action in your CI/CD
- name: Scan API Security
  uses: middlebrick/middlebrick-action@v1
  with:
    target_url: https://your-actix-app.com/api
    fail_on_score_below: 80

middleBrick's scanner specifically looks for Actix's request parsing behavior by sending crafted requests that test the boundaries between valid and malicious input. The scanner identifies whether your Actix application properly rejects requests with:

• Conflicting transfer encodings
• Invalid chunked encoding
• Header manipulation attempts

For manual detection, you can test your Actix application by sending requests with conflicting headers and observing the response. A properly configured Actix application should return a 400 Bad Request for requests with conflicting Content-Length and Transfer-Encoding headers.

Remediating HTTP Request Smuggling in Actix applications involves both configuration changes and code-level fixes. The most effective approach is to ensure your Actix application rejects ambiguous requests at the earliest possible stage.

First, configure Actix to reject requests with conflicting headers:

use actix_web::{dev::Payload, web, App, HttpMessage, HttpResponse, HttpServer};

async fn validate_request_headers(headers: &http::HeaderMap) -> Result<(), actix_web::Error> {
    // Check for conflicting Content-Length and Transfer-Encoding
    let has_content_length = headers.contains(http::header::CONTENT_LENGTH);
    let has_transfer_encoding = headers.contains(http::header::TRANSFER_ENCODING);
    
    if has_content_length && has_transfer_encoding {
        return Err(actix_web::error::ErrorBadRequest("Conflicting transfer encodings"));
    }
    
    Ok(())
}

async fn handle_request(
    headers: actix_web::http::header::HeaderMap,
    payload: web::Payload,
) -> HttpResponse {
    // Validate headers before processing
    if let Err(_) = validate_request_headers(&headers) {
        return HttpResponse::BadRequest().finish();
    }
    
    // Process request safely
    HttpResponse::Ok().finish()
}

For applications that must handle chunked encoding, implement strict boundary validation:

use actix_web::{web, App, HttpResponse, HttpServer};
use bytes::BytesMut;

async fn safe_chunked_handler(mut payload: web::Payload) -> HttpResponse {
    let mut buffer = BytesMut::new();
    let mut total_size = 0usize;
    
    while let Some(chunk) = payload.next().await {
        let chunk = chunk?;
        total_size += chunk.len();
        
        // Reject if size exceeds reasonable limits
        if total_size > 10_485_760 { // 10MB limit
            return HttpResponse::PayloadTooLarge().finish();
        }
        
        buffer.extend_from_slice(&chunk);
    }
    
    // Process buffer with validated chunk boundaries
    HttpResponse::Ok().finish()
}

Additionally, ensure your Actix application is deployed behind properly configured reverse proxies that normalize HTTP requests before they reach Actix. This creates a defense-in-depth approach where smuggling attempts are blocked at multiple layers.