Ssrf in Gin with Hmac Signatures

Server-Side Request Forgery (SSRF) in the Gin framework when HMAC signatures are used for request authentication can arise when a developer uses the signature to authorize an outbound request to a user-supplied URL without strict validation of the target. In this pattern, the client sends a URL and possibly a signature over that URL to a Gin endpoint. The server verifies the HMAC before forwarding the request to the supplied destination. If the signature only covers selected parameters but not the final target URL, or if the developer trusts the URL after signature validation, the server can be tricked into making arbitrary internal or external requests.

For example, an attacker may supply a URL that points to the Gin server’s own metadata service (169.254.169.254 on many cloud providers) or to internal services that are not exposed publicly. Because the server trusts its own HMAC verification, it forwards the request and returns the response to the attacker, effectively acting as a proxy. Common frameworks like Gin do not provide built-in SSRF protection; developers must implement allowlists, URL parsing, and network-level restrictions themselves. Even when using HMAC to ensure integrity of the parameters, the lack of destination validation creates a path for sensitive internal metadata or cloud instance credentials to be exfiltrated.

In a real-world scenario, an API might accept query parameters for a third-party resource and an HMAC to prevent tampering. If an attacker provides a URL like http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the server’s HMAC verification passes, the server can leak its own IAM instance profile credentials. This demonstrates that HMAC does not mitigate SSRF; it only ensures that the data format has not been altered. The vulnerability is not in HMAC itself but in how the verified data is used to construct network requests without proper SSRF controls such as URI allowlisting, host validation, and restricted network egress.

To remediate SSRF when using HMAC signatures in Gin, treat the signature as integrity protection only and enforce strict destination controls. Do not allow user-supplied URLs to point to private IP ranges, cloud metadata endpoints, or internal services unless explicitly permitted. Combine HMAC verification with an allowlist of permitted hosts and use a dedicated HTTP client with timeouts and network restrictions. Below are concrete, working examples for Gin that demonstrate secure handling.

First, define a helper to verify HMAC-SHA256 on incoming requests:

package main

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

func verifyHMAC(secret string, urlStr string, receivedMAC string) bool {
    mac := hmac.New(sha256.New, []byte(secret))
    mac.Write([]byte(urlStr))
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(expected), []byte(receivedMAC))
}

Next, implement an endpoint that validates the URL against an allowlist before making the request:

package main

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

var allowedHosts = map[string]bool{
    "api.example.com": true,
    "data.example.com": true,
}

func isHostAllowed(targetURL string) bool {
    u, err := url.Parse(targetURL)
    if err != nil {
        return false
    }
    return allowedHosts[u.Host]
}

func verifyHMAC(secret string, urlStr string, receivedMAC string) bool {
    mac := hmac.New(sha256.New, []byte(secret))
    mac.Write([]byte(urlStr))
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(expected), []byte(receivedMAC))
}

func proxyHandler(c *gin.Context) {
    target := c.Query("url")
    receivedMAC := c.Query("hmac")
    secret := "my-secret-key"

    if !verifyHMAC(secret, target, receivedMAC) {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid hmac"})
        return
    }

    if !isHostAllowed(target) {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "host not allowed"})
        return
    }

    // Safe to forward request; use a custom client with timeouts and restricted network policies in production
    resp, err := http.Get(target)
    if err != nil {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "request failed"})
        return
    }
    defer resp.Body.Close()

    // Forward response body or handle as needed
    c.Data(http.StatusOK, "application/octet-stream", nil) // placeholder
}

For automated CI/CD integration, the middleBrick CLI can be used to scan your Gin endpoints for SSRF and related issues. Run middlebrick scan <url> to detect misconfigurations and receive prioritized findings with remediation guidance. In production, combine this with the GitHub Action to fail builds if risk scores drop below your defined threshold, ensuring SSRF-prone patterns are caught before deployment.