Email Injection in Fiber with Hmac Signatures

Email injection is a class of injection flaws where untrusted data is concatenated into email headers or addresses, enabling header splitting, SMTP command injection, or routing manipulation. In a Fiber application, if user-controlled input (such as a display name, email address, or callback URL) is used to build email headers or messages and the application uses Hmac Signatures only for authentication of the request origin, the two mechanisms can interact in risky ways.

Consider a scenario where a Fiber handler accepts a user-supplied email address and a client-supplied Hmac signature. The developer may believe that the Hmac Signature validates the integrity and origin of the request, so any data taken from the request is considered safe. However, Hmac Signatures do not constrain or validate the semantic content of the payload. If the email value is used directly in an email header (for example in a MIME header or an SMTP transaction initiated by the server), newline characters (\r, \n) provided by an attacker can split the header and inject additional headers or SMTP commands.

Specifically, if the payload containing the email and the Hmac Signature is processed without canonicalization or strict validation, an attacker can supply an email such as: [email protected]\r\nCC: [email protected]\r\nSubject: Phishing. If the server embeds this value into an email message without sanitization, the injected CRLF sequences can cause the server or downstream mail transfer agent to interpret injected lines as new headers or commands. Because the request is authenticated via Hmac Signatures, the server may trust the origin and proceed to construct the email using the attacker-controlled data, leading to unintended recipients, forged headers, or even email relay abuse.

This becomes a practical concern when the Fiber server is used to generate or forward emails on behalf of users (for example, contact forms, invitation flows, or notification services). The presence of Hmac Signatures may give a false sense of security: they protect against tampering of known fields intended by the API designer, but they do not prevent misuse of fields that are interpreted by the email subsystem. The vulnerability is not in Hmac Signatures themselves, but in the lack of input validation and canonicalization of email headers combined with over-trust in authenticated requests.

An unauthenticated LLM endpoint or system prompt leakage is not directly involved here, but the principle is similar: without strict schema validation and output encoding, trusted channels (like authenticated requests with Hmac Signatures) can still propagate unsafe data to contexts where interpretation is dangerous. middleBrick scans would flag such issues under Property Authorization and Input Validation checks, highlighting where authenticated inputs are used in sensitive contexts without proper sanitization.

To remediate email injection when using Hmac Signatures in Fiber, treat authenticated input as untrusted for email header construction. Do not rely on the Hmac Signature to validate content; instead, enforce strict schema validation, canonicalize and encode data before using it in email headers, and avoid concatenating user data into header lines.

Below are concrete code examples for a Fiber handler that safely processes an email and an Hmac Signature.

1. Validate and sanitize the email address structurally (reject newlines and control characters), and use a dedicated email library to build headers rather than string concatenation.

package main

import (
	"crypto/hmac"
	"crypto/sha256"
	"encoding/hex"
	"fmt"
	"net/mail"
	"net/smtp"
	"strings"

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

// verifyHmac returns true if the payload+signature matches the key.
func verifyHmac(payload, signature, secret string) bool {
	h := hmac.New(sha256.New, []byte(secret))
	h.Write([]byte(payload))
	expected := hex.EncodeToString(h.Sum(nil))
	return hmac.Equal([]byte(expected), []byte(signature))
}

func main() {
	app := fiber.New()

	app.Post("/notify", func(c *fiber.Ctx) error {
		// Example secret key — in production, use env/config.
		const secret = "super-secret-key"

		// Read raw body or specific fields; here we assume JSON with email and hmac_signature.
		type Req struct {
			Email          string `json:"email"`
			HmacSignature  string `json:"hmac_signature"`
			Message        string `json:"message"`
		}
		var req Req
		if err := c.BodyParser(&req); err != nil {
			return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid_body"})
		}

		// Reconstruct the payload that was signed (must match server and client).
		payload := fmt.Sprintf(`{"email":"%s","message":"%s"}`, req.Email, req.Message)
		if !verifyHmac(payload, req.HmacSignature, secret) {
			return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid_signature"})
		}

		// Strict validation: reject newlines and control characters in email.
		if strings.ContainsAny(req.Email, "\r\n") {
			return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid_email"})
		}

		// Parse using net/mail to ensure it's a valid address and to avoid header injection.
		addr, err := mail.ParseAddress(req.Email)
		if err != nil {
			return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid_email_format"})
		}

		// Use smtp.SendMail with properly constructed headers; do not embed raw user input into header lines.
		header := make(map[string]string)
		header["From"] = "[email protected]"
		header["To"] = addr.Address // single, validated address
		header["Subject"] = "Notification"
		// For additional headers, set them explicitly and avoid concatenation.
		header["Message-ID"] = ""

		// Build the message safely.
		var msgLines []string
		for k, v := range header {
			msgLines = append(msgLines, fmt.Sprintf("%s: %s", k, v))
		}
		msgLines = append(msgLines, "") // blank line before body
		msgLines = append(msgLines, req.Message)
		msg := strings.Join(msgLines, "\r\n")

		// Example SMTP send (configure server/auth as needed).
		// smtp.SendMail("smtp.example.com:587", nil, "[email protected]", []string{addr.Address}, []byte(msg))

		return c.JSON(fiber.Map{"status": "queued", "to": addr.Address})
	})

	app.Listen(":3000")
}

2. If you must include multiple recipients, use explicit lists and avoid building comma-separated strings from user input; validate each address individually.

3. For advanced scenarios involving templates, use a templating engine with context-aware escaping for header fields, and ensure that no user-controlled newline characters can enter header values. middleBrick’s Input Validation and Property Authorization checks will help identify places where authenticated data reaches email-related code paths without sufficient sanitization.