Server Side Template Injection in Actix with Hmac Signatures

Server Side Template Injection (SSTI) in Actix applications can be compounded when Hmac Signatures are used to bind request data to a trusted context. SSTI occurs when an attacker can control a template input that is later rendered by a server-side template engine, enabling code execution or information disclosure. In Actix-based Rust services, templates are often rendered using engines like askama or tera, and developers may use Hmac Signatures to ensure the integrity of parameters such as user IDs, session tokens, or feature flags that influence which template logic is executed.

If the Hmac-signed data is accepted from the client, verified only for integrity (not safety), and then interpolated into a template variable without strict validation or escaping, an attacker who can guess or leak a valid Hmac may craft payloads that traverse the signature check. Because the signature confirms data authenticity but not safety, the application may proceed to render attacker-controlled strings as part of the template context. This can lead to SSTI if the template engine treats injected objects as executable expressions, particularly when combined with dynamic template selection or conditional rendering based on signed fields.

For example, an endpoint may accept a query parameter template_id, sign it with Hmac, and later use it to select a template path. If the signature is valid but the value is not restricted to a known safe set, an attacker can supply a template name that maps to a malicious template containing SSTI primitives. Even when using sandboxed template engines, complex object graphs passed into the template can expose methods or properties that enable reflection-based code execution, especially when the data originates from an Hmac-verified source assumed to be trustworthy.

In the context of middleBrick’s checks, this scenario maps to the BOLA/IDOR and Input Validation categories, where unauthenticated attack surface testing reveals that trusted-scope data (protected by Hmac) is not sufficiently sanitized before rendering. Because middleBrick scans the unauthenticated endpoints and cross-references OpenAPI specs with runtime behavior, it can flag cases where Hmac-signed parameters flow into template rendering paths without type or enum constraints, highlighting the risk even though the signature mechanism itself remains intact.

Remediation focuses on never allowing Hmac-verified data to directly influence template selection or variable content used in rendering. Validate and constrain all inputs before they are considered safe, even if the Hmac confirms integrity. Use strict allowlists for template identifiers, and avoid passing raw user-influenced data into template contexts.

Below are concrete Actix examples in Rust. The first shows an unsafe pattern where an Hmac-signed query parameter is used to select a template name. The second shows a secure refactor that decouples user input from template selection and ensures all variables passed to the engine are non-executable.

Unsafe pattern (demonstrating the risk)

use actix_web::{web, HttpResponse};
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct TemplateRequest {
    template_id: String,
    signature: String,
}

async fn render_template_unsafe(
    req: web::Query,
) -> HttpResponse {
    // Insecure: signature verified, but template_id used directly
    let valid = verify_hmac(&req.template_id, &req.signature);
    if !valid {
        return HttpResponse::BadRequest().finish();
    }
    // Assume `render` is a function that uses the template_id to load a template
    let body = render(&req.template_id, &serde_json::json!({}));
    HttpResponse::Ok().body(body)
}

fn verify_hmac(data: &str, signature: &str) -> bool {
    // Placeholder: real Hmac verification logic
    true
}

Secure remediation with allowlist and safe context

use actix_web::{web, HttpResponse};
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct TemplateRequest {
    template_id: String,
    signature: String,
}

#[derive(Serialize)]
struct SafeTemplateContext {
    user_id: u64,
    environment: &'static str,
}

async fn render_template_safe(
    req: web::Query,
) -> HttpResponse {
    // Verify Hmac integrity
    let valid = verify_hmac(&req.template_id, &req.signature);
    if !valid {
        return HttpResponse::BadRequest().finish();
    }

    // Strict allowlist: only known-safe templates can be selected
    let template_name = match req.template_id.as_str() {
        "profile" => "profile_template",
        "welcome" => "welcome_template",
        _ => return HttpResponse::BadRequest().body("unsupported template"),
    };

    // Build a safe, non-user-controlled context
    let context = SafeTemplateContext {
        user_id: 12345,
        environment: "production",
    };

    let body = render(template_name, &context);
    HttpResponse::Ok().body(body)
}

fn verify_hmac(data: &str, signature: &str) -> bool {
    // Placeholder: real Hmac verification logic
    true
}

fn render(name: &str, ctx: &SafeTemplateContext) -> String {
    // Placeholder: real rendering logic, e.g., using askama or tera
    format!("rendered {} with {:?}", name, ctx)
}

Additional guidance: keep Hmac usage limited to integrity checks for transport or session tokens, and do not rely on it for authorization or input safety. Combine with Actix’s extractor validation and strict schema constraints (e.g., using serde with deny_unknown_fields) to reduce the attack surface. Where LLM security is a concern, note that middleBrick’s LLM/AI Security checks can identify endpoints where signed parameters may still leak system prompts or enable prompt injection when those values are reflected in model interactions.