Arp Spoofing in Axum with Saml

Arp spoofing is a Layer 2 attack where an adversary sends falsified Address Resolution Protocol messages to associate their MAC address with the IP of a legitimate host, such as an identity provider or a service endpoint in an Axum application that processes SAML assertions. In an environment where SAML-based single sign-on is used, an attacker on the same local network can intercept and modify communication between a user’s browser and the Axum service, redirecting SAML request or response traffic through the attacker’s machine.

When SAML flows rely on predictable network paths and unverified link-layer behavior, arp spoofing can expose metadata and assertions in transit. Axum applications that rely on HTTP redirects for SAML bindings (e.g., redirect binding for SAML responses) may inadvertently route manipulated traffic to an unintended endpoint if the underlying network is compromised. Because SAML messages often carry session tokens and NameID values, interception via arp spoofing can lead to token replay or identity confusion, especially when transport layer protections are not strictly enforced or when service providers fail to validate the origin of requests rigorously.

The risk is not in SAML itself being weak, but in the network layer failing to protect the integrity of associations required for secure assertion delivery. In Axum, if services do not enforce strict source validation and rely only on application-level checks, arp spoofing can facilitate man-in-the-middle scenarios that undermine the trust chain established by SAML signatures and certificates. Complementary issues such as missing strict transport security or improper endpoint binding amplify the impact, allowing attackers to inject or alter authentication flows without immediate detection.

Securing SAML flows in Axum requires both network-aware practices and strict application-level validation. While arp spoofing is primarily a network issue, robust SAML implementations reduce impact by validating every assertion, enforcing secure transport, and binding sessions to the expected endpoints. Below are concrete remediation steps and code examples tailored for Axum services consuming SAML responses.

Enforce HTTPS and Strict Transport Security

Ensure all SAML endpoints are served over HTTPS and that your Axum service rejects any HTTP requests for those paths. Use middleware to enforce TLS and to require the Secure and HttpOnly flags on cookies.

use axum::middleware::from_fn;
use axum::routing::post;
use axum::{Router, http::HeaderMap};

async fn validate_https(
    headers: HeaderMap,
) -> Result<(), (axum::http::StatusCode, String)> {
    if headers.get("x-forwarded-proto")
        .and_then(|v| v.to_str().ok())
        .map(|s| s == "https")
        .unwrap_or(false)
    {
        Ok(())
    } else {
        Err((axum::http::StatusCode::FORBIDDEN, "HTTPS required".into()))
    }
}

let app = Router::new()
    .route("/acs", post(consume_assertion))
    .layer(from_fn(validate_https));

Validate SAML Response Signature and Issuer

Always verify the digital signature of incoming SAML responses and confirm that the issuer matches your configured identity provider. Do not rely on URL-based routing alone to determine trust. Use a SAML library that supports signature validation and certificate pinning.

use saml2::core::protocol::Response;
use saml2::metadata::IdpMetadata;
use saml2::validate::SignatureValidator;

async fn consume_assertion(
    saml_response: String,
) -> Result {
    let metadata = IdpMetadata::from_file("/path/to/idp-metadata.xml")
        .map_err(|e| (axum::http::StatusCode::BAD_REQUEST, e.to_string()))?;
    let validator = SignatureValidator::new(metadata);
    let response: Response = validator.validate_signature(&saml_response)
        .map_err(|e| (axum::http::StatusCode::BAD_REQUEST, e.to_string()))?;

    // Additional checks: audience, issuer, not_before/not_on_or_after
    if response.issuer() != &metadata.entity_id {
        return Err((axum::http::StatusCode::FORBIDDEN, "Invalid issuer".into()));
    }
    // Continue with subject and session creation
    Ok((axum::http::StatusCode::OK, "SAML assertion accepted"))
}

Bind Sessions to Assertion Context

After validating a SAML response, bind the session to the assertion’s context, including the NameID and any confirming source identifiers. This binding helps detect replay attempts that might be enabled via arp spoofing or session hijacking.

use axum::extract::State;
use std::sync::Arc;

struct SessionStore { /* fields */ }

async fn create_session(
    State(store): State>,
    name_id: String,
    session_index: String,
) -> Result {
    // Store a binding between session, NameID, and confirming source
    store.insert(name_id, session_index).await;
    Ok((axum::http::StatusCode::SEE_OTHER, "Redirect to app".into()))
}

Network-Level Hardening

While not SAML-specific, mitigate arp spoofing by ensuring your deployment runs on networks where Layer 2 spoofing is restricted (e.g., using port security, static ARP entries, or host-based firewall rules). Document these controls as part of your secure deployment checklist.

Compliance Mapping

These practices align with OWASP API Security Top 10 controls around authentication integrity and transport protections, and they support compliance requirements found in PCI-DSS, SOC2, and GDPR for secure handling of identity data.