Out Of Bounds Write in Actix with Jwt Tokens

An Out Of Bounds Write in an Actix-based API that handles JWT tokens typically arises when application code manually parses or modifies token payloads using fixed-size buffers or unchecked string operations. JWTs consist of three dot-separated base64url-encoded parts. If an Actix handler deserializes these parts into fixed-length structures or byte arrays without validating lengths, an attacker-supplied token with an oversized payload can write beyond intended memory boundaries during copy operations.

Consider an endpoint that extracts a custom claim from a JWT to enforce tenant scope. If the developer assumes a fixed claim size and uses a fixed-size array (e.g., [u8; 256]) to hold a decoded claim value, an oversized claim can cause an out-of-bounds write. This can corrupt adjacent memory, leading to undefined behavior or potentially enabling control-flow manipulation. Although Rust’s safety mitigations reduce exploitability compared to lower-level languages, unsafe blocks or unchecked indexing can reintroduce the risk.

In the context of middleBrick’s checks, this vulnerability may surface across multiple security categories. For example, the Input Validation check flags missing length checks on token fields, while the Property Authorization check highlights missing verification of claim ownership across tenants. An attacker could craft a JWT with an extremely long custom claim or a deeply nested payload to trigger the out-of-bounds condition during processing. Because the scan is unauthenticated, middleBrick can detect endpoints where token parsing logic appears to rely on brittle, size-assumed structures without proper bounds enforcement.

Additionally, if the Actix service uses unsafe Rust to interface with C libraries or optimized parsers while processing JWTs, the boundary checks may be bypassed. middleBrick’s LLM/AI Security checks do not apply here, but the scanner’s Input Validation and Unsafe Consumption checks can surface risky patterns such as unchecked get_unchecked usage or raw pointer operations tied to token handling.

To illustrate a vulnerable pattern, the following example shows an Actix handler that manually decodes a JWT and copies a claim into a fixed-size buffer without length validation:

use actix_web::{web, HttpResponse, Result};
use base64::engine::general_purpose::STANDARD_NO_PAD;
use base64::Engine;

fn parse_claim(token: &str) -> Option<[u8; 256]> {
    let parts: Vec<&str> = token.split('.').collect();
    if parts.len() != 3 {
        return None;
    }
    let decoded = STANDARD_NO_PAD.decode(parts[1])?;
    let mut claim = [0u8; 256];
    claim[..decoded.len()].copy_from_slice(&decoded);
    Some(claim)
}

async fn handler(token: web::Query) -> Result {
    let token_str = token.token.trim_start_matches("Bearer ");
    if let Some(claim) = parse_claim(token_str) {
        // Use claim in a bounded context
        Ok(HttpResponse::Ok().body(format!("Claim hash: {:x?}", &claim[..32])))
    } else {
        Ok(HttpResponse::BadRequest().body("Invalid token"))
    }
}

In this snippet, if the payload decoded from the JWT’s middle part exceeds 256 bytes, the copy_from_slice will panic in safe Rust. However, if the code uses unchecked indexing or an unsafe block to truncate or extend the copy, it may write past the array boundary. middleBrick’s scan would highlight the missing length validation and the unsafe handling pattern, guiding developers to use dynamic structures like Vec or bounded slices with explicit checks.

Remediation focuses on eliminating fixed-size buffers and ensuring strict length checks before any copy or cast operation involving JWT-derived data. In Actix, prefer high-level deserialization with well-maintained libraries that handle base64url decoding and claims mapping safely.

Instead of manually splitting and copying token segments into fixed arrays, use a crate such as jsonwebtoken to validate and decode the token, and map claims into a dynamically sized structure. This approach removes the need for manual length management and prevents out-of-bounds writes.

The following example demonstrates a secure pattern using jsonwebtoken with Actix, where claims are bound to a struct with owned String fields, avoiding fixed-size buffers entirely:

use actix_web::{web, HttpResponse, Result};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    tenant_id: String,
    exp: usize,
    custom_data: String,
}

fn validate_token(token: &str) -> Result {
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::(
        token,
        &DecodingKey::from_secret("secret".as_ref()),
        &validation,
    )?;
    Ok(token_data.claims)
}

async fn handler(token: web::Query) -> Result {
    let token_str = token.token.trim_start_matches("Bearer ");
    match validate_token(token_str) {
        Ok(claims) => {
            // Use claims fields directly; they are owned Strings with dynamic sizing
            if claims.tenant_id == "expected-tenant" {
                Ok(HttpResponse::Ok().body(format!("User: {}", claims.sub)))
            } else {
                Ok(HttpResponse::Forbidden().body("Unauthorized tenant"))
            }
        }
        Err(_) => Ok(HttpResponse::BadRequest().body("Invalid token")),
    }
}

If you must work with raw token segments for advanced use cases, always compute the exact length after base64url decoding and allocate buffers dynamically using Vec. Avoid fixed-size arrays unless the maximum size is rigorously proven and enforced. For example:

use actix_web::{web, HttpResponse, Result};
use base64::engine::general_purpose::STANDARD_NO_PAD;
use base64::Engine;

fn safe_extract_custom_field(token: &str) -> Option> {
    let parts: Vec<&str> = token.split('.').collect();
    if parts.len() != 3 {
        return None;
    }
    let decoded = STANDARD_NO_PAD.decode(parts[1]).ok()?;
    // Use Vec for dynamic sizing; no fixed-size buffer
    Some(decoded)
}

async fn handler(token: web::Query) -> Result {
    let token_str = token.token.trim_start_matches("Bearer ");
    if let Some(data) = safe_extract_custom_field(token_str) {
        // Process data with explicit bounds checks
        if data.len() > 32 {
            Ok(HttpResponse::Ok().body(format!("First 32 bytes: {:x?}", &data[..32])))
        } else {
            Ok(HttpResponse::Ok().body(format!("Full payload: {:x?}", data)))
        }
    } else {
        Ok(HttpResponse::BadRequest().body("Invalid token"))
    }
}

These patterns align with the remediation guidance provided by middleBrick’s findings: validate token structure, avoid fixed buffers, and enforce length checks before any copy. By integrating the CLI tool (middlebrick scan <url>) or the GitHub Action, you can automatically detect missing bounds checks in your Actix services and prevent regressions in future commits.