Open Redirect in Gorilla Mux with Hmac Signatures

An Open Redirect in a Gorilla Mux router becomes high risk when Hmac Signatures are used to validate a redirect target. The vulnerability occurs when a handler reads a destination URL from an untrusted source (for example, a query parameter) and then uses an Hmac signature to decide whether to trust that target. If the signature is computed only over the destination URL or over a subset of parameters that an attacker can influence, an attacker can forge a valid signature without knowing the secret.

Consider a pattern where a user is sent to a URL like /login?redirect=https://trusted.example.com/dashboard&sig=.... If the server verifies the Hmac over the full query string but does not enforce a strict allowlist of permitted hosts, the attacker can set redirect to a malicious host and compute a valid sig by including attacker-controlled parameters that the server also includes in the signature base string. Because Gorilla Mux routes are matched before handler execution, the handler may extract the redirect parameter and perform the redirect without re-validating the host against a strict permit list, resulting in an open redirect.

Another scenario involves using Hmac to bind a token to a redirect target. If the token is stored in a cookie or header and the signature is computed over the redirect URL alone, an attacker who can set a subdomain or path on the same origin might be able to craft a valid redirect to a malicious external site. The risk is compounded when the signature does not include a timestamp or nonce, enabling replay of the signed redirect. This matters because an open redirect can be used for phishing lures or to bypass referrer-based protections. In the context of the 12 security checks run by middleBrick, this pattern would typically be flagged under Input Validation and Property Authorization, since the redirect target is user-influenced and the authorization logic around it is insufficient.

Real-world attack patterns mirror this: an application generates a signed redirect to an OAuth provider or a post-login landing page, but the allowlist check is missing or applied after the signature verification. For example, an attacker might supply redirect=https://evil.com and, if the signature scheme is weak or includes too many mutable query keys, produce a valid link that the server will follow. middleBrick’s detection of Input Validation and BOLA/IDOR findings highlights cases where redirect parameters are not properly constrained before being used in sensitive flows.

To remediate, enforce a strict allowlist of permitted redirect hosts and include contextual values such as a timestamp or nonce in the Hmac computation. Never trust the redirect target solely based on signature validity; validate the parsed URL against an allowlist before performing the redirect.

Example: Signed redirect with host allowlist and timestamp

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
    "net/http"
    "net/url"
    "strings"
    "time"

    "github.com/gorilla/mux"
)

var signingKey = []byte("your-secure-secret-key")
var allowedHosts = map[string]bool{
    "app.example.com": true,
    "dashboard.example.com": true,
}

func verifySignedRedirect(w http.ResponseWriter, r *http.Request) {
    redirect := r.URL.Query().Get("redirect")
    sig := r.URL.Query().Get("sig")
    timestamp := r.URL.Query().Get("ts")

    if redirect == "" || sig == "" || timestamp == "" {
        http.Error(w, "missing required parameters", http.StatusBadRequest)
        return
    }

    // Reject if the timestamp is too old (e.g., >2 minutes) to prevent replay
    ts, err := time.Parse("20060102150405", timestamp)
    if err != nil || time.Since(ts) > 2*time.Minute {
        http.Error(w, "invalid timestamp", http.StatusBadRequest)
        return
    }

    // Build the base string exactly as the signer used it
    base := "redirect=" + redirect + "&ts=" + timestamp
    expectedSig := computeHmac(base)

    if !hmac.Equal([]byte(expectedSig), []byte(sig)) {
        http.Error(w, "invalid signature", http.StatusBadRequest)
        return
    }

    parsed, err := url.Parse(redirect)
    if err != nil {
        http.Error(w, "invalid redirect URL", http.StatusBadRequest)
        return
    }

    if !allowedHosts[parsed.Host] {
        http.Error(w, "redirect not allowed", http.StatusBadRequest)
        return
    }

    http.Redirect(w, r, redirect, http.StatusFound)
}

func computeHmac(message string) string {
    mac := hmac.New(sha256.New, signingKey)
    mac.Write([]byte(message))
    return hex.EncodeToString(mac.Sum(nil))
}

func handler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    // Example: build a redirect with a timestamp and sign it
    ts := time.Now().UTC().Format("20060102150405")
    target := "https://app.example.com/dashboard"
    base := "redirect=" + target + "&ts=" + ts
    sig := computeHmac(base)
    url := "/login?redirect=" + url.QueryEscape(target) + "&ts=" + ts + "&sig=" + sig
    http.Redirect(w, r, url, http.StatusTemporaryRedirect)
}

This example demonstrates: (1) including a timestamp to mitigate replay, (2) computing the Hmac over a canonical string that both client and server agree on, and (3) validating the parsed host against an allowlist before issuing the redirect. By combining these controls, you eliminate the ability for an attacker to supply a malicious redirect that passes signature verification.

Example: Using middleware to validate signed redirect parameters

func secureRedirectMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Only apply to specific routes if needed
        if strings.Contains(r.URL.Path, "/login") {
            verifySignedRedirect(w, r)
            return
        }
        next.ServeHTTP(w, r)
    })
}

func main() {
    r := mux.NewRouter()
    r.HandleFunc("/login", handler).Methods("GET")
    r.Use(secureRedirectMiddleware)
    http.ListenAndServe(":8080", r)
}

With these patterns, the signature ties the redirect to a time-bound token while the server independently ensures the target host is permitted. This approach aligns with secure design guidance that treats external URLs as untrusted, even when a cryptographic signature is present. In practice, using middleBrick’s scans can help detect missing host allowlists and weak signature scopes during development and CI/CD via the GitHub Action and MCP Server integrations.