Email Injection in Gin with Cockroachdb

Email injection occurs when user-controlled input is concatenated into email headers or commands without proper validation or escaping. In a Gin application using Cockroachdb, this typically manifests when building email-related functionality—such as invite, notification, or password reset flows—where user-supplied fields like email, name, or subject are stored in Cockroachdb and later used to construct raw email messages or passed to external mail commands/scripts.

Because Cockroachdb is a PostgreSQL-compatible database, string values are often inserted via SQL using standard placeholders. However, if the application layer builds email headers or shell commands using string concatenation before or after storing data, injection can occur at two boundaries: the SQL boundary (if placeholders are not used) and the email/command boundary (if data from Cockroachdb is interpolated into mail utilities or scripts). For example, storing an email address like attacker@example.com\r\nSubject: Malicious in Cockroachdb and later embedding it in a mail command or SMTP transaction can cause header injection, enabling spam relay or phishing.

The Gin framework does not provide built-in email sanitization; developers must explicitly validate and encode user input. When combined with Cockroachdb’s SQL interface, the risk arises if developers mistakenly treat stored email values as safe simply because they come from a database. A compromised or malicious entry in Cockroachdb can therefore become a vector for outbound email abuse when Gin templates or handlers re-use that data in email contexts without re-validation or encoding.

Consider an endpoint that registers a user and stores their email in Cockroachdb, then later uses that email in a raw SMTP transaction constructed via string formatting in Go. An attacker could supply an email header delimiter (e.g., %0a%0aSubject: Free Money) which, if the database stores it verbatim and the Go code does not sanitize, results in injected headers when the stored value is read and used. This illustrates how Gin routing, Cockroachdb persistence, and email generation interact to create a chain of trust that can be broken by insufficient input validation and output encoding.

To assess this using middleBrick, you would submit the Gin endpoint URL for an unauthenticated scan. The LLM/AI Security checks and input validation tests would probe for header injection patterns, while the API specification analysis would cross-reference any documented email parameters against runtime behavior to highlight missing encoding or validation.

Remediation centers on strict input validation, using Cockroachdb placeholders, and encoding data at the point of use (e.g., email headers or commands). Below are concrete Go examples for a Gin handler that stores a user’s email in Cockroachdb and later uses it safely.

1. Safe storage with Cockroachdb using placeholders

Always use parameterized SQL to avoid injection at the database layer. Do not interpolate user input into query strings.

// Example using `pgx` with Cockroachdb in Gin
import (
    "context"
    "github.com/jackc/pgx/v5/pgxpool"
    "net/http"
)

func registerEmail(pool *pgxpool.Pool) gin.HandlerFunc {
    return func(c *gin.Context) {
        var req struct {
            Email string `json:"email" binding:"required,email"`
        }
        if err := c.ShouldBindJSON(&req); err != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }
        // Use a placeholder; Cockroachdb accepts $1, $2, etc.
        _, err := pool.Exec(context.Background(), "INSERT INTO users(email) VALUES($1)", req.Email)
        if err != nil {
            c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to store email"})
            return
        }
        c.JSON(http.StatusOK, gin.H{"status": "ok"})
    }
}

2. Encode data when constructing email headers

When reading email addresses from Cockroachdb for email construction, sanitize and encode to prevent header injection. Use mail.Address for formatted headers and avoid direct concatenation.

import (
    "net/mail"
    "net/smtp"
)

func sendWelcomeEmailFromDB(rowEmail string) error {
    // Encode the address to prevent header injection
    addr := mail.Address{Name: "Service", Address: rowEmail}
    to := addr.String()
    // Use smtp.SendMail with proper authentication; never build raw headers via string concatenation
    msg := []byte("To: " + to + "\r\n" +
        "Subject: Welcome\r\n" +
        "Content-Type: text/plain; charset=utf-8\r\n" +
        "\r\n" +
        "Welcome!")
    auth := smtp.PlainAuth("", "smtp_user", "smtp_pass", "smtp.example.com")
    return smtp.SendMail("smtp.example.com:587", auth, "noreply@example.com", []string{to}, msg)
}

3. Validate and sanitize on output, not just on input

Even when using Cockroachdb placeholders, re-validate and encode when using stored values in contexts like email or shell commands. For example, if you generate a link or invoke a mail script, ensure the email is normalized and does not contain control characters or delimiters.

import (
    "regexp"
    "strings"
)

var headerDelimiters = regexp.MustCompile(`[\r\n]`)

func sanitizeEmailForHeader(email string) string {
    // Remove or replace CR/LF to prevent header injection
    return headerDelimiters.ReplaceAllString(email, "")
}

func buildInviteEmail(storedEmail string) string {
    clean := sanitizeEmailForHeader(storedEmail)
    return "Please visit https://app.example.com/invite?email=" + clean
}

4. Avoid shelling out with raw data from Cockroachdb

If you must invoke external commands, pass arguments via structured APIs rather than building command strings with data from Cockroachdb. If unavoidable, rigorously escape or use language-specific functions (e.g., strconv.Quote).

import (
    "os/exec"
    "strconv"
)

func notifyViaScript(emailFromDB string) error {
    // Escape arguments to prevent command injection
    emailArg := strconv.Quote(emailFromDB)
    cmd := exec.Command("/usr/local/bin/notify", "--email", emailArg)
    return cmd.Run()
}