sec(email): sanitize AccountName/Provider in SES registration subject - #566
Conversation
cristim
added
triaged
|
Warning Review limit reached
More reviews will be available in 54 minutes and 31 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis PR adds defense-in-depth against CR/LF header injection: it strips CR/LF and caps AccountName length at registration input, and applies header sanitization to AccountName and Provider when composing the SES email subject. ChangesCRLF Header Injection Mitigation
Sequence DiagramsequenceDiagram
participant Client
participant submitRegistration
participant validateRegistrationRequest
participant SendRegistrationReceivedNotification
participant SES
Client->>submitRegistration: POST /api/register (RegistrationRequest)
submitRegistration->>validateRegistrationRequest: validate & sanitize *RegistrationRequest (strip CR/LF, truncate)
validateRegistrationRequest-->>submitRegistration: sanitized request
submitRegistration->>SendRegistrationReceivedNotification: send notification (sanitized AccountName, Provider)
SendRegistrationReceivedNotification->>SES: SendEmail with sanitized subject
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@internal/api/handler_registrations_validate_test.go`:
- Around line 3-9: The test currently checks the account name cap using
len(req.AccountName) which measures bytes not runes; update the assertion to use
unicode/utf8.RuneCountInString(req.AccountName) and add an import for
"unicode/utf8" so the cap test verifies rune count (rune-safe) for
req.AccountName instead of byte length; keep the same assertion semantics but
replace len(...) with utf8.RuneCountInString(...).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 81f67947-ffd7-4aee-9b01-ab738f2a4f3f
📒 Files selected for processing (4)
internal/api/handler_registrations.gointernal/api/handler_registrations_validate_test.gointernal/email/templates.gointernal/email/templates_test.go
|
Addressed in 5ecc6cf: the length-cap test now uses a multibyte rune and asserts via |
5ecc6cf to
9bf5707
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai resolve |
✅ Actions performedComments resolved. Approval is disabled; enable |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
9bf5707 to
32f6ecd
Compare
|
CR finding #discussion_r3275573192 - confirmed resolved. The fix was in commit 9bf5707 (now rebased to 32f6ecd on current base):
@coderabbitai review |
|
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/api/handler_registrations.go (1)
408-419:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winReject whitespace-only
account_nameafter CR/LF normalization.After CR/LF stripping, inputs like
" \r\n "become whitespace-only and currently pass Line 418’s emptiness check. Trim before required validation so effectively empty names are rejected.Proposed fix
func validateRegistrationRequest(req *RegistrationRequest) error { req.AccountName = strings.NewReplacer("\r", "", "\n", "").Replace(req.AccountName) + req.AccountName = strings.TrimSpace(req.AccountName) if r := []rune(req.AccountName); len(r) > maxAccountNameLen { req.AccountName = string(r[:maxAccountNameLen]) } @@ if req.AccountName == "" { return NewClientError(400, "account_name is required") }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/api/handler_registrations.go` around lines 408 - 419, Normalize req.AccountName with CR/LF stripping as done, then immediately call strings.TrimSpace on the result and assign back to req.AccountName before doing the rune-length truncation and the emptiness check; ensure the truncation (the rune slice using maxAccountNameLen) and the subsequent validation that returns NewClientError(400, "account_name is required") operate on the trimmed value so whitespace-only names are rejected.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@internal/api/handler_registrations.go`:
- Around line 408-419: Normalize req.AccountName with CR/LF stripping as done,
then immediately call strings.TrimSpace on the result and assign back to
req.AccountName before doing the rune-length truncation and the emptiness check;
ensure the truncation (the rune slice using maxAccountNameLen) and the
subsequent validation that returns NewClientError(400, "account_name is
required") operate on the trimmed value so whitespace-only names are rejected.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 61dcac91-69f8-4c2d-9759-5ca6a20acb3e
📒 Files selected for processing (4)
internal/api/handler_registrations.gointernal/api/handler_registrations_validate_test.gointernal/email/templates.gointernal/email/templates_test.go
After stripping CR/LF the account_name could still be whitespace-only (spaces, tabs), which passed the empty-string guard and produced an SES subject line containing `Account "": `. Add strings.TrimSpace after the CR/LF replacement so the existing empty-string check also catches that case. Adds a regression test: POST with account_name " \t " must return 400 with "account_name is required". Closes finding on PR #566 (CR review 2026-05-22).
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
PR #523 fixed only the SMTP registration-subject path. The SES path (SendRegistrationReceivedNotification in internal/email/templates.go) still built the "CUDly - New Account Registration: %s (%s)" subject from raw, attacker-controlled data.AccountName and data.Provider sourced from the unauthenticated POST /api/register endpoint, then passed it to the SES SendEmail API. A CR+LF in account_name could inject extra email headers. Wrap both fields in the existing sanitizeHeader helper (reused from the SMTP path) and add defense-in-depth at the data source: validateRegistrationRequest now strips CR/LF and length-caps account_name in place. Adds regression tests on the SES subject path and the handler normalizer. Closes #544.
CodeRabbit flagged that the length-cap test measured byte length while the implementation caps by rune count, so the ASCII-only input never exercised rune-safety. Switch the input to a multibyte rune, assert via utf8.RuneCountInString, and verify the truncated result is still valid UTF-8.
After stripping CR/LF the account_name could still be whitespace-only (spaces, tabs), which passed the empty-string guard and produced an SES subject line containing `Account "": `. Add strings.TrimSpace after the CR/LF replacement so the existing empty-string check also catches that case. Adds a regression test: POST with account_name " \t " must return 400 with "account_name is required". Closes finding on PR #566 (CR review 2026-05-22).
2556944 to
923720c
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
1 participant
Summary
data.AccountNameanddata.Providerwith the existingsanitizeHeaderhelper in the SES registration-subject path (SendRegistrationReceivedNotificationininternal/email/templates.go), closing the CRLF email-header-injection vector that PR sec(email): set TLS 1.2 minimum on SMTP StartTLS and sanitize registration subject #523 left open after fixing only the SMTP path.validateRegistrationRequestnow strips CR/LF and rune-safe length-capsaccount_namein place, so the cleaned value flows into both persistence and the email.Why
Per #401, the SES path is the more dangerous of the two unsanitized sinks: it receives attacker-controlled input from the unauthenticated
POST /api/registerendpoint. PR #523 wrapped only the SMTP subject insanitizeHeader, leaving the SESSendEmailsubject built from rawAccountName/Provider.Test plan
go build ./...go test ./internal/email/... ./internal/api/...(1471 tests pass)TestSender_SendRegistrationReceivedNotification_SubjectHeaderInjectionmocks SES, captures theSendEmailInput, and asserts the subject reaching SES has no CR/LF and no injected header names.TestValidateRegistrationRequest_AccountNameSanitizedcovers CRLF stripping, length capping, and rejection of a CRLF-only name.Closes #544.
Summary by CodeRabbit
Bug Fixes
Tests