Ssrf Server Side in Buffalo with Hmac Signatures

Server-side request forgery (SSRF) in a Buffalo application that uses Hmac Signatures for external request authentication can expose both authentication bypass and internal network reachability issues. When a Buffalo handler builds a request to an upstream service and signs it with a shared secret, developers may assume the signature protects the call. However, if the target URL or parameters used to build the request are attacker-controlled, an attacker can force the server to make requests to internal endpoints that the Hmac verification does not protect, because the signature is only validated on the recipient side or used only for outbound authenticity.

Consider a Buffalo app that accepts a URL path to fetch data from a backend API and signs the request using an Hmac derived from a shared secret and selected headers. If the user-supplied path or host is not strictly validated, the server can be coerced into making requests to internal services such as the metadata service at http://169.254.169.254 or internal Kubernetes endpoints like http://kubernetes.default.svc. The Hmac signature generated by the app may include only the outgoing headers, but does not prevent the server from initiating connections to internal IPs or cloud instance metadata endpoints. This combination magnifies SSRF because the attacker leverages the app’s trusted outbound request mechanism to probe internal infrastructure, while the Hmac logic focuses on proving request integrity to third parties, not on constraining where the request may go.

In Buffalo, if URL construction or redirection logic uses unchecked user input to form the request target, the Hmac verification step does not mitigate SSRF. For example, an endpoint that builds a request with http.Client and signs it may still allow an attacker to specify a malicious internal IP or a sensitive AWS metadata endpoint. Since the app trusts its own signature generation, it may fail to validate the final resolved host and port, allowing the request to reach internal services that would otherwise be unreachable from the internet. This demonstrates how SSRF can persist even when Hmac Signatures are used, provided the validation of the request target is weak or absent.

To detect such issues, scanners perform black-box testing by submitting manipulated URLs and inspecting whether the server follows unexpected redirects or reaches internal endpoints. The presence of Hmac Signatures does not inherently prevent SSRF; it only authenticates outbound traffic. Developers must treat user-controlled URLs as hostile and enforce strict allowlists on hosts and ports, and avoid forwarding requests to internal services based on unvalidated input.

Remediation centers on strict input validation and canonical request construction. Do not allow user input to directly dictate the target host or port. Instead, maintain an allowlist of permitted upstream services and construct the request URL server-side. When signing, canonicalize the request method, path, selected headers, and timestamp to prevent ambiguity. Below is a concrete example of a Buffalo handler that validates the target service against an allowlist, builds the request safely, and signs it using Hmac-SHA256 without exposing internal endpoints.

package actions

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

	"github.com/gobuffalo/buffalo"
)

var allowedUpstreams = map[string]bool{
	"https://api.example.com/data": true,
	"https://api.example.com/status": true,
}

func SignedFetch(c buffalo.Context) error {
	// Accept only a service key, not a raw URL
	serviceKey := c.Param("service")
	path, ok := allowedUpstreams[serviceKey]
	if !ok {
		c.Response().WriteHeader(http.StatusBadRequest)
		c.Response().Write([]byte(`{"error":"invalid service"}`))
		return nil
	}

	// Build the request to the allowed upstream
	req, err := http.NewRequest("GET", serviceKey, nil)
	if err != nil {
		c.Response().WriteHeader(http.StatusInternalServerError)
		return err
	}

	// Add required headers for the upstream
	req.Header.Set("Accept", "application/json")
	req.Header.Set("X-Request-ID", c.Request().Header.Get("X-Request-ID"))

	// Create canonical string for signing: method, path, selected headers
	canonical := req.Method + "\n" + req.URL.RequestURI() + "\n" + req.Header.Get("X-Request-ID")
	signature := generateHmac(canonical, []byte("your-shared-secret"))

	// Attach the signature in a header for the upstream to verify
	req.Header.Set("X-Signature", signature)

	client := &http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		c.Response().WriteHeader(http.StatusBadGateway)
		return err
	}
	defer resp.Body.Close()

	// Forward response or handle as needed
	c.Response().WriteHeader(resp.StatusCode)
	_, _ = c.Response().Write([]byte(`{"status":"ok"}`))
	return nil
}

func generateHmac(message string, secret []byte) string {
	h := hmac.New(sha256.New, secret)
	h.Write([]byte(message))
	return hex.EncodeToString(h.Sum(nil))
}

Key points in the fix:

• Use an allowlist keyed to full URLs rather than accepting arbitrary target URLs from the client.
• Construct the http.Request server-side to ensure the final host is controlled and cannot redirect to internal endpoints.
• Include only safe headers in the Hmac canonical string and avoid forwarding untrusted headers that could influence routing.
• Sign the method, path, and a nonce or request identifier to bind the signature to the intended request, reducing replay risks.

Additionally, apply network-level controls such as egress filtering and ensure that the application cannot reach metadata or internal endpoints. These measures together eliminate the SSRF vector while preserving the integrity provided by Hmac Signatures.