mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-07 22:01:36 +00:00
shankar0123
3853b7460c
H-3 in certctl-audit-report.md: caller-supplied From/To/Subject were
interpolated directly into the SMTP DATA payload and handed to
client.Mail / client.Rcpt with no sanitization, allowing an attacker
who controls any of those values to inject extra headers (Bcc:,
Reply-To:), split the message body (CRLFCRLF), or tamper with the
SMTP envelope. CWE-113.
Fix:
- New package helper internal/validation.ValidateHeaderValue(field,
value). Rejects CR ("\r"), LF ("\n"), and NUL ("\x00") with an error
that names the offending field but does NOT echo the raw value,
so log readers cannot be attacked with injected content. Silent
stripping was considered and rejected: authentication-relevant
headers must fail visibly.
- Two-layer defense in internal/connector/notifier/email/email.go:
(1) primary guard at the top of sendEmail / sendHTMLEmail, which
blocks tampering of the SMTP envelope (client.Mail, client.Rcpt)
since net/smtp does not sanitize those arguments; and
(2) defense-in-depth guard inside formatEmailMessage /
formatHTMLEmailMessage, catching any future caller that
bypasses sendEmail. Both format functions now return an error.
- Body content is intentionally NOT validated — CR/LF in body is legal
RFC 5322 content and net/smtp handles dot-stuffing.
Tests:
- internal/validation/headers_test.go: 3 functions (AcceptsSafeInput,
RejectsControlCharacters, DefaultFieldName) covering plain ASCII,
UTF-8 multibyte, tabs, typical email addresses, CRLF injection,
lone CR, lone LF, NUL, CRLFCRLF body split, trailing CR, leading LF.
Each reject case asserts the field name IS in the error and the
raw offending value IS NOT (anti-log-injection).
- internal/connector/notifier/email/email_test.go: added
TestEmail_FormatEmailMessage_RejectsCRLFInjection and
TestEmail_FormatHTMLEmailMessage_RejectsCRLFInjection. Existing
format tests updated for the new (bytes, error) signature.
Wire-format invariants preserved:
- SMTP DATA headers still use CRLF separators and RFC 1123Z Date
(unchanged).
- Content-Type headers unchanged (text/plain for plain, text/html +
MIME-Version: 1.0 for HTML).
- No change to message encoding or transport.
Verification (Go 1.25.9 linux-arm64, parent e9947dc):
- go build ./... clean
- go vet ./... clean
- go test -race ./internal/validation/... ok
- go test -race ./internal/connector/notifier/email/... ok
- go test -race ./internal/connector/notifier/webhook/... ok
- Per-layer coverage gates all pass:
validation 95.1% (+0.7 vs baseline 94.4%)
email 39.7% (+1.4 vs baseline 38.3%)
service 67.8% (unchanged)
handler 78.6% (unchanged)
middleware 80.0% (unchanged)
domain 92.7% (unchanged)
- govulncheck ./... No vulnerabilities found
- golangci-lint run ./internal/validation/... ./internal/connector/notifier/email/...
0 issues
Operational note: SMTP sends that would previously deliver a
tampered message now fail fast at the notifier with a clear error.
Operators who were relying on header-injection-shaped inputs (there
should be none in practice — all callers are internal certctl code)
will see "failed to format message: <field> contains disallowed
control character" in logs.
Scope: H-3 only. H-4 (webhook SSRF) follows in a separate commit.
37 lines
1.2 KiB
Go
37 lines
1.2 KiB
Go
package validation
|
|
|
|
import (
|
|
"fmt"
|
|
"strings"
|
|
)
|
|
|
|
// ValidateHeaderValue rejects any value that contains characters capable of
|
|
// breaking out of a header line and injecting additional headers or body
|
|
// content. It guards against CRLF injection (CWE-113) in RFC 5322 message
|
|
// headers (SMTP, IMAP, etc.) and RFC 7230 HTTP headers alike.
|
|
//
|
|
// Disallowed characters:
|
|
// - Carriage return ("\r")
|
|
// - Line feed ("\n")
|
|
// - NUL ("\x00")
|
|
//
|
|
// The field name is included in the returned error solely for operator
|
|
// diagnostics; the offending value is not echoed back, so untrusted input
|
|
// does not leak into logs that render this error.
|
|
//
|
|
// Callers should invoke this on any string that will be interpolated into a
|
|
// header (From, To, Subject, Reply-To, custom X-* headers, etc.) before the
|
|
// headers are serialized. Values containing CR/LF/NUL MUST be rejected
|
|
// outright; silent stripping is inappropriate for authentication-relevant
|
|
// headers because it can mask malicious intent while still altering the
|
|
// message.
|
|
func ValidateHeaderValue(field, value string) error {
|
|
if field == "" {
|
|
field = "header"
|
|
}
|
|
if strings.ContainsAny(value, "\r\n\x00") {
|
|
return fmt.Errorf("%s contains disallowed control character (CR, LF, or NUL)", field)
|
|
}
|
|
return nil
|
|
}
|