Bleichenbacher Attack in Actix with Jwt Tokens

A Bleichenbacher attack is a chosen-ciphertext attack against RSA-based padding schemes, commonly RSAES-PKCS1-v1_5. In the context of Actix web applications that use JWT tokens with RSA signatures (for example, RS256), this attack can be relevant if the application performs signature verification in a way that leaks information via timing or error behavior. Actix is a Rust web framework; if JWT validation is implemented manually or with a library that does not use constant-time verification, an attacker can iteratively send modified tokens and observe differences in response times or error messages to gradually recover the private key or forge tokens.

When JWT tokens use RSA signatures, the public key verifies the signature. If the server returns distinct errors for invalid signatures versus invalid padding, an attacker can exploit these side channels. In an Actix service, this often occurs when JWT validation logic is implemented with naive pattern matching or non-constant-time checks rather than a vetted, high-level JWT library. For example, if an endpoint decodes the token, separates the header, payload, and signature, and then performs RSA verification with custom logic, subtle timing differences or error responses can expose the padding validity to an attacker.

Consider an Actix handler that manually parses and verifies a JWT using an RSA public key. If the handler returns 401 for malformed tokens and 403 for signature verification failures, an attacker can use timing measurements and error codes to conduct a Bleichenbacher-style adaptive attack. This is compounded if the application uses small keys or does not enforce strict padding checks. The attack does not break RSA mathematically but exploits the implementation’s behavior when handling invalid ciphertexts. Because JWT tokens are often passed in Authorization headers, repeated requests with slightly altered signatures can allow an attacker to learn about the padding structure and eventually forge valid tokens without the private key.

To assess whether an Actix service is vulnerable, security scans check whether JWT validation is performed using constant-time operations and whether error handling is uniform. MiddleBrick’s 12 security checks include Input Validation and Authentication, which can detect timing discrepancies and improper error handling in API responses. These checks analyze runtime behavior against the OpenAPI/Swagger spec and identify whether the API exposes distinguishable error states for invalid JWT tokens. If the scan finds that verification logic is not hardened against adaptive attacks, it may flag the endpoint as part of the Authentication or Input Validation findings, providing remediation guidance to use standard libraries and constant-time verification.

Remediation centers on using a well-maintained, constant-time JWT library and ensuring uniform error handling in Actix. Avoid manual parsing and RSA verification; rely on libraries that implement strict padding checks and do not leak timing information. Below are concrete code examples for secure JWT validation in Actix using the jsonwebtoken crate with RSA keys.

Secure JWT validation in Actix (RS256)

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

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

/// Load RSA public key from PEM (e.g., from environment or config).
fn get_public_key() -> Vec {
    std::fs::read("public_key.pem").expect("Unable to read public key")
}

/// Actix handler with secure JWT validation.
async fn protected_route(token: String) -> Result {
    let public_key = get_public_key();
    let decoding_key = DecodingKey::from_rsa_pem(&public_key)
        .map_err(|_| HttpResponse::Unauthorized().finish())?;

    let validation = Validation::new(Algorithm::RS256);
    // Enforce strict validation: reject tokens with invalid signatures or padding.
    let token_data = decode::(&token, &decoding_key, &validation)
        .map_err(|_| HttpResponse::Unauthorized().finish())?;

    // Use token_data.claims as needed; ensure errors do not distinguish padding vs signature failures.
    Ok(HttpResponse::Ok().json(token_data.claims))
}

Key points in the example:

• DecodingKey::from_rsa_pem parses the PEM-encoded RSA public key. Do not use from_rsa_components with raw parameters unless you are certain the library handles padding securely.
• Validation::new(Algorithm::RS256) sets the expected algorithm; do not relax validation or allow Algorithm::HS256 when RSA is intended.
• Both decoding failures and invalid signatures map to the same HTTP 401 response, preventing information leakage via status codes or timing.
• Ensure the RSA key size is sufficient (e.g., 2048 bits or higher) and that the public key is pinned or managed via a trusted source.

If you use Actix extractors, wrap validation in a custom extractor that returns a uniform error type. This further reduces the risk of side-channel leaks. MiddleBrick’s GitHub Action can validate that your CI/CD pipeline rejects API changes that introduce non-constant-time JWT handling or weak key sizes.

Comparing configurations

For broader API security, the Pro plan’s continuous monitoring can detect whether your endpoints exhibit timing variability that may indicate vulnerabilities. The MCP Server allows you to run scans directly from your IDE while developing Actix services, ensuring JWT handling remains hardened against adaptive attacks.