Side Channel Attack in Axum with Basic Auth

A side channel attack in Axum using Basic Auth exploits timing or behavioral differences that leak information about authentication outcomes without directly compromising credentials. When a server processes an invalid versus a valid username, the observable behavior—such as response time, HTTP status code, or body content—can differ in measurable ways. For example, a developer might implement a check that first validates the username format, then performs a password comparison only when the username exists. This introduces a timing discrepancy because an attacker can infer valid usernames by measuring response latency.

In Axum, Basic Auth is typically extracted from the Authorization header using helper utilities. If the implementation branches based on whether a user exists in a repository before proceeding to password verification, an attacker can send many requests with guessed usernames and observe subtle timing differences. These differences can be amplified in networked environments where connection pooling or TLS handshake behavior adds noise, but statistical analysis can still reveal patterns. The vulnerability is not in the protocol itself but in how the application uses it; poor integration choices turn a standardized mechanism into an information leak.

The 12 security checks run by middleBrick operate in parallel and include Authentication, Input Validation, and Rate Limiting, which can surface indirect indicators of a side channel. For instance, inconsistent response times across usernames may be detected as anomalous behavior under authentication testing. Similarly, missing rate limiting can enable an attacker to send a high volume of probes to amplify timing differences. Even without accessing protected resources, the scan can identify risk patterns by correlating authentication paths with observable variations. This aligns with the broader category of side channel exploitation, where indirect signals replace direct attacks.

Consider an endpoint that uses middleware to extract and verify credentials. If the middleware resolves a user ID from the database and then calls a password comparison function only when the ID is found, the control flow becomes data-dependent. An attacker can send requests with non-existent usernames and measure whether responses complete faster than those with valid usernames. Although Axum does not prescribe a specific implementation, idiomatic patterns that conditionally skip hashing or early-return on missing users create these branches. middleBrick’s authentication checks highlight such risks by examining whether authentication logic applies uniformly across all inputs.

To contextualize this within real-world attack patterns, consider how timing information can be correlated with other inputs. For example, an attacker might combine timing side channels with credential stuffing using known username lists. While Axum itself does not introduce the flaw, frameworks that encourage inconsistent handling of missing users increase the attack surface. The LLM/AI Security checks in middleBrick do not directly test for side channels, but they can identify unsafe patterns such as unauthenticated endpoint exposure that may compound risk. Ultimately, the mitigation focuses on ensuring that authentication paths execute in constant time and avoid branching on sensitive data.

Remediation in Axum centers on making authentication logic constant-time and avoiding early exits based on username existence. Instead of returning when a user is not found, the application should proceed through a uniform verification flow that performs a dummy computation to mask timing differences. This prevents attackers from inferring valid usernames through latency measurements.

Below is a secure Axum handler example that uses a repository interface to abstract user lookup and password verification. The key design choice is to always invoke a verification routine that runs in constant time, regardless of whether the username exists. The example uses Option to represent presence without branching on authentication outcome in the handler path.

use axum::{
    async_trait,
    extract::FromRequest,
    http::{
        header::{AUTHORIZATION, HeaderValue},
        Request,
        StatusCode,
    },
    response::IntoResponse,
};
use std::convert::Infallible;
use hmac::{Hmac, Mac};
use sha2::Sha256;
type HmacSha256 = Hmac;

#[async_trait]
pub trait UserRepository {
    async fn find_user_by_username(&self, username: &str) -> Option;
    async fn verify_password(&self, user: &User, password: &str) -> bool;
}

pub struct User {
    pub id: u64,
    pub username: String,
    // password_hash would be stored as a secure type in practice
    pub password_hash: String,
}

pub async fn verify_basic_auth(
    repo: R,
    username: &str,
    password: &str,
) -> bool {
    let user = repo.find_user_by_username(username).await;
    // Always run verification with a dummy user to keep timing consistent
    let dummy_user = User {
        id: 0,
        username: String::new(),
        password_hash: String::new(),
    };
    let target_user = user.unwrap_or(dummy_user);
    repo.verify_password(&target_user, password).await
}

// Axum extractor implementation
pub struct AuthenticatedUser(User);

#[async_trait]
impl FromRequest for AuthenticatedUser
where
    S: Send + Sync,
{
    type Rejection = (StatusCode, &'static str);

    async fn from_request(req: Request) -> Result {
        let auth_header = req
            .headers()
            .get(AUTHORIZATION)
            .ok_or((StatusCode::UNAUTHORIZED, "Missing Authorization header"))?;
        let header_str = auth_header
            .to_str()
            .map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid header encoding"))?;
        if !header_str.starts_with("Basic ") {
            return Err((StatusCode::UNAUTHORIZED, "Invalid auth method"));
        }
        let encoded = &header_str[6..];
        let decoded = base64::decode(encoded)
            .map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid base64"))?;
        let creds = String::from_utf8(decoded)
            .map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid credentials format"))?;
        let mut parts = creds.splitn(2, ':');
        let username = parts.next().ok_or((StatusCode::UNAUTHORIZED, "Missing username"))?;
        let password = parts.next().ok_or((StatusCode::UNAUTHORIZED, "Missing password"))?;

        // In practice, inject your repository here
        let repo = InMemoryRepository::new();
        let is_valid = verify_basic_auth(repo, username, password).await;
        if is_valid {
            let user = repo.find_user_by_username(username).await
                .ok_or((StatusCode::UNAUTHORIZED, "User not found after verification"))?;
            Ok(AuthenticatedUser(user))
        } else {
            // Return a generic rejection without revealing which part failed
            Err((StatusCode::UNAUTHORIZED, "Invalid credentials"))
        }
    }
}

// Example in-memory repository for illustration
struct InMemoryRepository {
    users: Vec,
}

impl InMemoryRepository {
    fn new() -> Self {
        Self { users: vec![] }
    }
}

#[async_trait]
impl UserRepository for InMemoryRepository {
    async fn find_user_by_username(&self, username: &str) -> Option {
        self.users.iter().find(|u| u.username == username).cloned()
    }

    async fn verify_password(&self, user: &User, password: &str) -> bool {
        // Use a constant-time comparison in production
        user.password_hash == password // Simplified for example; use proper hashing
    }
}