Crlf Injection in Axum with Dynamodb

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) sequences into a header or a value that is later reflected into an HTTP response or a backend request. In an Axum application that uses Amazon DynamoDB as a persistence layer, this typically happens when user-controlled input is read from the request, stored in DynamoDB, and later used to construct HTTP headers, redirect URLs, or log entries that are interpreted by downstream clients or internal tooling.

Consider an endpoint that accepts a user ID, fetches profile data from DynamoDB, and returns a Location header for a redirect. If the profile item stored in DynamoDB contains a value like \r\nSet-Cookie: session=attacker, and Axum uses that value directly when building a response, the injected CRLF sequences can split the header and inject additional headers or response lines. This becomes a security boundary issue because DynamoDB itself is only a storage layer; the risk emerges when Axum reads data from DynamoDB and places it into a context where CRLF characters are interpreted by an HTTP server or client (e.g., browser, proxy, or log parser).

In Axum, this often maps to the following chain: an HTTP request triggers a handler that queries DynamoDB using the AWS SDK for Rust; the handler retrieves an item (e.g., user profile or configuration) and uses field values to construct headers, redirect URLs, or log lines. If the item contains untrusted data and Axum does not validate or sanitize newlines, a stored injection can become a live injection when the data is rendered in an HTTP context. Because DynamoDB stores items as attribute-value maps, newlines can be stored as literal \r\n sequences if they were allowed during insertion (for example, from a rich text field or an improperly validated input). Axum then surfaces these values in headers, which many Rust HTTP stacks will process line-by-line, treating CRLF as a delimiter.

Real-world impact examples include response splitting to inject crafted headers, bypassing browser protections, or manipulating log streams that are later parsed by tooling. While DynamoDB does not interpret CRLF, Axum’s usage of retrieved data in headers or redirects creates the exploitable path. This is a classic example of how a backend service like DynamoDB becomes part of a larger injection chain when combined with an application framework like Axum that builds HTTP messages from stored data.

Remediation focuses on validating and sanitizing data retrieved from DynamoDB before it is used in HTTP headers, redirects, or logs. In Axum, you should treat any value coming from DynamoDB as potentially untrusted and apply context-specific encoding or rejection. Below are concrete code examples that show how to implement this safely in Rust with the AWS SDK for Rust.

First, define a validation helper that checks for embedded CRLF sequences in strings retrieved from DynamoDB. This helper can be used before inserting values into headers or constructing redirect URLs.

/// Reject strings containing CR or LF characters.
fn assert_no_crlf(value: &str) -> Result<(), String> {
    if value.contains('\r') || value.contains('\n') {
        Err(format!("Invalid newline character in value: {}", value))
    } else {
        Ok(())
    }
}

Use this validator in your Axum handlers after retrieving items from DynamoDB. For example, when building a Location header for a redirect, validate each dynamic component.

use axum::{http::HeaderValue, response::Redirect};
use aws_sdk_dynamodb::Client;

async fn profile_redirect_handler(
    Path(user_id): Path,
    db: web::Data,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let item = db.get_item()
        .table_name("profiles")
        .key("user_id", AttributeValue::S(user_id.clone()).into())
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?
        .item
        .ok_or_else(|| (StatusCode::NOT_FOUND, "Profile not found".to_string()))?;

    let location_path = item.get("path")
        .and_then(|v| v.as_s().ok())
        .map(String::from)
        .unwrap_or_else(|| "/default".to_string());

    // Validate before using in redirect
    assert_no_crlf(&location_path)?;

    let redirect_url = format!("/{}", location_path);
    let location_header = HeaderValue::from_str(&redirect_url)
        .map_err(|_| (StatusCode::BAD_REQUEST, "Invalid redirect URL"))?;

    Ok(Redirect::see_other(location_header).into_response())
}

When storing data into DynamoDB, apply the same validation at the boundary of user input to prevent malicious values from being persisted. This ensures that even if later reads occur, the stored values are safe for any intended use.

async fn create_profile(
    db: web::Data,
    new_profile: Json<NewProfile>
) -> Result<impl IntoResponse, (StatusCode, String)> {
    assert_no_crlf(&new_profile.display_name)?;
    assert_no_crlf(&new_profile.bio.unwrap_or_default())?;

    db.put_item()
        .table_name("profiles")
        .set_item(Some({
            let mut map = HashMap::new();
            map.insert("user_id".to_string(), AttributeValue::S(new_profile.user_id.clone()).into());
            map.insert("display_name".to_string(), AttributeValue::S(new_profile.display_name.clone()).into());
            map.insert("bio".to_string(), AttributeValue::S(new_profile.bio.clone().unwrap_or_default()).into());
            map
        }))
        .send()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(StatusCode::CREATED.into_response())
}

For logging purposes, avoid directly inserting DynamoDB values into log lines that may be parsed by structured loggers. If you must log these values, sanitize them or use a logging framework that treats newlines as safe or escapes them explicitly.

Additionally, prefer using framework-level extractors and guards in Axum to centralize validation. You can create a tower layer or extractor that checks for CRLF across all user-influenced inputs, reducing the chance of missing a vector when data flows from DynamoDB into headers, cookies, or URLs.