Open Redirect in Fiber with Hmac Signatures

An Open Redirect in a Fiber application that uses Hmac Signatures can occur when a redirect target is derived from user-controlled input and the Hmac protection is applied incompletely or inconsistently. For example, an endpoint may accept a next parameter, compute an Hmac over the raw query string or selected parameters, and then redirect to the provided URL without verifying that the target is an allowed origin. If the Hmac does not cover the redirect destination (or covers only a subset of the request), an attacker can supply a malicious URL while still presenting a valid signature for the parts that are covered, leading to an unrestricted redirect.

Consider a login flow that appends a token and an Hmac to the query string: /login?token=abc&signature=HMAC(secret, token). If the server validates the Hmac against the token but then redirects to the value of a separate, unsigned parameter such as url, the signature does not protect the destination. An attacker can craft a link like /login?token=abc&signature=valid&url=https://evil.com, pass signature verification, and cause the application to redirect unauthenticated users to a malicious site. This pattern is common in OAuth-like flows and post-login redirects where the destination is supplied by the client.

Even when Hmac Signatures are used, the risk arises if the application trusts the incoming URL without re-deriving the signature scope to include the redirect target. Because Hmac Signatures bind specific parameters to a secret, omitting the redirect parameter from the signed payload means the server cannot detect tampering. An attacker does not need to break the Hmac; they simply provide a new, unsigned parameter that the server uses directly. The presence of Hmac Signatures may create a false sense of integrity if developers assume that signature validation alone prevents open redirects, without ensuring that all user-influenced data involved in the redirect decision is covered by the Hmac.

In practice, this misalignment between what is signed and what is used for redirection can lead to phishing or session fixation. For instance, an attacker might send a victim a link that appears valid because the token and signature check out, but the final destination is an attacker-controlled domain. Because the signature does not bind the redirect target, the victim’s browser is redirected, potentially to a page that mimics the original application. This is especially dangerous when the redirect is used for post-authentication flows or cross-site navigation where the user is less likely to scrutinize the final URL.

To detect this pattern, a scanner evaluates whether the set of parameters included in the Hmac computation encompasses all parameters that influence server-side redirection logic. If the signature scope is narrower than the redirect inputs, the endpoint is flagged. The scanner also checks whether the application performs allowlist-based validation of redirect targets, as this is a strong control that mitigates open redirect risks regardless of signature usage.

Remediation centers on ensuring that the Hmac covers all parameters used to determine the redirect target. In Fiber, this means including the redirect parameter (e.g., url or next) in the data that is signed, and recomputing the Hmac on the server side over the exact same set of key-value pairs before using the parameter for redirection.

Below is a secure example in Go using Fiber where the Hmac is computed over both the token and the redirect URL, and the signature is verified before any redirection occurs. The code uses crypto/hmac and crypto/sha256 to generate and validate the signature, and it performs an allowlist check on the redirect host to enforce strict destination policies.

package main

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

    "github.com/gofiber/fiber/v2"
)

var secretKey = []byte("your-strong-secret-key")

func computeHmac(token, redirectURL string) string {
    mac := hmac.New(sha256.New, secretKey)
    mac.Write([]byte(token))
    mac.Write([]byte("&"))
    mac.Write([]byte(redirectURL))
    return hex.EncodeToString(mac.Sum(nil))
}

func isValidRedirect(rawURL string) bool {
    parsed, err := url.Parse(rawURL)
    if err != nil {
        return false
    }
    allowedHosts := map[string]bool{"app.example.com": true, "app.example.org": true}
    return allowedHosts[parsed.Host]
}

func loginHandler(c *fiber.Ctx) error {
    token := c.Query("token")
    redirectURL := c.Query("url")
    receivedSig := c.Query("signature")

    expectedSig := computeHmac(token, redirectURL)
    if !hmac.Equal([]byte(expectedSig), []byte(receivedSig)) {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid signature"})
    }

    if !isValidRedirect(redirectURL) {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "redirect not allowed"})
    }

    return c.Redirect(redirectURL)
}

func main() {
    app := fiber.New()
    app.Get("/login", loginHandler)
    app.Listen(":3000")
}

Key points in this approach:

• The Hmac is computed over both the token and the redirect URL using a deterministic encoding (token & '&' & url).
• The server recomputes the signature using the exact same method before using the url parameter, ensuring that any tampering with the redirect target invalidates the signature.
• An allowlist check on the parsed host prevents redirection to disallowed domains, providing defense-in-depth even if the signature validation were bypassed.
• Using hmac.Equal mitigates timing attacks during signature comparison.

If your existing flow signs only the token, you should extend the signed payload to include the redirect parameter and rotate the signature verification logic accordingly. It is also important to normalize inputs (e.g., trim whitespace, enforce lowercase schemes) before signing and verification to avoid subtle mismatches. For API clients that cannot be changed to include the redirect in the signature, consider returning a server-side redirect token that maps to an allowlisted destination rather than using raw user-supplied URLs.

• Does using Hmac Signatures alone prevent open redirects in Fiber applications? No. Hmac Signatures only protect the integrity of the specific parameters included in the signed payload. If the redirect target is not covered by the Hmac, an attacker can supply a malicious URL that passes signature checks and causes an open redirect.
• What is a robust way to scope Hmac coverage for redirects in Fiber? Include all user-influenced data used in the redirect decision (such as the token and the destination URL) in the Hmac computation, and enforce an allowlist of permitted redirect hosts on the server before performing any redirection.