DAW/furt

Fork 0

Remove real API key exposure from email content #115

New issue

Open

opened 2025-09-10 21:21:48 +02:00 by michael · 1 comment

michael commented

2025-09-10 21:21:48 +02:00

Owner

Problem

furt currently exposes real API keys in email content, creating serious security risks.

Current Vulnerable Code

Email content includes:

Website: Dragons@Work Website Production (daw_f8k2m9xp7q3n6w5z8c1v4b8j0s9e2r5t)
From: Production Deployment <admin@dragons-at-work.de>
Subject: furt v0.1.2 Production Success

[content]

---
Sent via Furt Gateway
API Key: Dragons@Work Website Production
Request ID: 1757523404-1058

Security Risks

1. Real API Key Exposure

Website: [...] (daw_f8k2m9xp7q3n6w5z8c1v4b8j0s9e2r5t)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                REAL API KEY - CRITICAL SECURITY RISK

2. Attack Vectors

Email Interception: Man-in-the-middle attacks
Mail Server Storage: Plaintext API keys in mail databases
Email Forwarding: Keys exposed when emails are forwarded
Mail Client Caching: Local storage of sensitive credentials
Backup Systems: API keys in mail backup systems
Log Analysis: Keys visible in mail server logs

3. Impact Assessment

Unauthorized API Access: Attackers can use exposed keys
Service Abuse: Rate limit exhaustion via stolen keys
Data Exfiltration: Access to protected endpoints
Reputation Damage: Security breach exposure

Root Cause Analysis

File: src/smtp.lua

-- Current problematic implementation
local email_content = string.format(
    "Website: %s (%s)\n" ..     -- ← API KEY EXPOSED HERE
    "From: %s <%s>\n" ..
    "Subject: %s\n\n%s\n\n" ..
    "---\n" ..
    "Sent via Furt Gateway\n" ..
    "API Key: %s\n" ..          -- ← REDUNDANT (but harmless - just name)
    "Request ID: %s",
    website_name,
    api_key,                    -- ← REAL KEY = SECURITY PROBLEM
    form_data.name,
    form_data.email,
    form_data.subject,
    form_data.message,
    api_key_name,               -- ← HARMLESS (just display name)
    request_id
)

Solution Implementation

1. Remove Real API Key from Email Content

Replace:

-- BEFORE (vulnerable)
Website: %s (%s)
website_name, api_key  -- ← REMOVE REAL KEY

-- AFTER (secure)  
Website: %s
website_name          -- ← ONLY DISPLAY NAME

2. Improve Email Signature

Current (redundant):

---
Sent via Furt Gateway
API Key: Dragons@Work Website Production  ← REDUNDANT
Request ID: 1757523404-1058

Improved (minimal):

---
Sent via Dragons@Work Contact Form
Request ID: 1757523404-1058

3. Enhanced Security Approach

-- Secure email content format
local email_content = string.format(
    "From: %s <%s>\n" ..
    "Subject: %s\n" ..
    "Website: %s\n\n" ..        -- ← NO API KEY
    "%s\n\n" ..
    "---\n" ..
    "Contact via Dragons@Work\n" ..
    "Request ID: %s",
    form_data.name,
    form_data.email,
    form_data.subject,
    website_name,               -- ← SAFE: Only display name
    form_data.message,
    request_id                  -- ← SAFE: Public request ID
)

Code Changes Required

File: src/smtp.lua

Function: Email content formatting (around line 275)

Changes:

Remove API key from Website field
Simplify email signature
Keep Request ID for tracking (safe)
Remove redundant API key name line

Security Validation

# Test email content should NOT contain:
grep -E "[a-z0-9]{32,}" email_content.txt
# → Should return empty (no long random strings)

# Should contain safe identifiers only:
grep "Request ID:" email_content.txt  
grep "Website:" email_content.txt
# → Safe tracking without credentials

Testing Strategy

1. Security Review

Email content contains NO real API keys
Only safe display names in email
Request ID preserved for tracking
No sensitive data in email body

2. Functionality Validation

Email delivery still works
Request tracking functional
User experience unchanged
Admin can identify source website

3. Security Audit

mail-tester.com validation (content scan)
Email interception simulation
Log analysis for credential leaks
Multiple email provider testing

Impact Assessment

Immediate Benefits

✅ Eliminates API key exposure in email content
✅ Reduces attack surface significantly
✅ Maintains functionality (tracking, identification)
✅ Improves professional appearance (cleaner emails)

Risk Mitigation

✅ No credential exposure via email interception
✅ Safe email forwarding (no sensitive data)
✅ Secure mail server storage (no plaintext credentials)
✅ Audit-trail compliance (no sensitive data in logs)

Priority Justification

Why High Priority:

Security-Critical: Real credentials exposed in plaintext
Easy Fix: Simple code change, low implementation risk
High Impact: Eliminates major security vulnerability
Production Active: Issue exists in live production system

Success Criteria

Before Fix (Vulnerable)

Website: Dragons@Work Website Production (daw_f8k2m9xp7q3n6w5z8c1v4b8j0s9e2r5t)
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                          EXPOSED API KEY = SECURITY RISK

After Fix (Secure)

Website: Dragons@Work Website Production
                                        ^^^^^^^^
                                        SAFE - NO CREDENTIALS

Additional Security Considerations

1. Logging Review

Review furt logs for API key exposure
Ensure request logs don't contain credentials
Implement log sanitization if needed

2. Historical Email Audit

Check if previous emails contained API keys
Consider API key rotation if exposure confirmed
Review mail server logs for credential storage

3. Future Prevention

Code review checklist: "No credentials in user-facing content"
Automated testing for credential exposure
Security scanning in CI/CD pipeline

Files Involved

src/smtp.lua (primary fix location)
docs/security.md (add security guidelines)
tests/security_test.lua (credential leak testing)

Estimated Effort

Fix Implementation: 15 minutes
Testing & Validation: 30 minutes
Security Review: 15 minutes
Total: ~1 hour

Simple change, massive security improvement.

## Problem furt currently exposes **real API keys** in email content, creating serious security risks. ## Current Vulnerable Code **Email content includes:** ``` Website: Dragons@Work Website Production (daw_f8k2m9xp7q3n6w5z8c1v4b8j0s9e2r5t) From: Production Deployment <admin@dragons-at-work.de> Subject: furt v0.1.2 Production Success [content] --- Sent via Furt Gateway API Key: Dragons@Work Website Production Request ID: 1757523404-1058 ``` ## Security Risks ### 1. Real API Key Exposure ``` Website: [...] (daw_f8k2m9xp7q3n6w5z8c1v4b8j0s9e2r5t) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ REAL API KEY - CRITICAL SECURITY RISK ``` ### 2. Attack Vectors - **Email Interception**: Man-in-the-middle attacks - **Mail Server Storage**: Plaintext API keys in mail databases - **Email Forwarding**: Keys exposed when emails are forwarded - **Mail Client Caching**: Local storage of sensitive credentials - **Backup Systems**: API keys in mail backup systems - **Log Analysis**: Keys visible in mail server logs ### 3. Impact Assessment - **Unauthorized API Access**: Attackers can use exposed keys - **Service Abuse**: Rate limit exhaustion via stolen keys - **Data Exfiltration**: Access to protected endpoints - **Reputation Damage**: Security breach exposure ## Root Cause Analysis **File: src/smtp.lua** ```lua -- Current problematic implementation local email_content = string.format( "Website: %s (%s)\n" .. -- ← API KEY EXPOSED HERE "From: %s <%s>\n" .. "Subject: %s\n\n%s\n\n" .. "---\n" .. "Sent via Furt Gateway\n" .. "API Key: %s\n" .. -- ← REDUNDANT (but harmless - just name) "Request ID: %s", website_name, api_key, -- ← REAL KEY = SECURITY PROBLEM form_data.name, form_data.email, form_data.subject, form_data.message, api_key_name, -- ← HARMLESS (just display name) request_id ) ``` ## Solution Implementation ### 1. Remove Real API Key from Email Content **Replace:** ```lua -- BEFORE (vulnerable) Website: %s (%s) website_name, api_key -- ← REMOVE REAL KEY -- AFTER (secure) Website: %s website_name -- ← ONLY DISPLAY NAME ``` ### 2. Improve Email Signature **Current (redundant):** ``` --- Sent via Furt Gateway API Key: Dragons@Work Website Production ← REDUNDANT Request ID: 1757523404-1058 ``` **Improved (minimal):** ``` --- Sent via Dragons@Work Contact Form Request ID: 1757523404-1058 ``` ### 3. Enhanced Security Approach ```lua -- Secure email content format local email_content = string.format( "From: %s <%s>\n" .. "Subject: %s\n" .. "Website: %s\n\n" .. -- ← NO API KEY "%s\n\n" .. "---\n" .. "Contact via Dragons@Work\n" .. "Request ID: %s", form_data.name, form_data.email, form_data.subject, website_name, -- ← SAFE: Only display name form_data.message, request_id -- ← SAFE: Public request ID ) ``` ## Code Changes Required ### File: src/smtp.lua **Function:** Email content formatting (around line 275) **Changes:** 1. **Remove API key** from Website field 2. **Simplify email signature** 3. **Keep Request ID** for tracking (safe) 4. **Remove redundant** API key name line ### Security Validation ```bash # Test email content should NOT contain: grep -E "[a-z0-9]{32,}" email_content.txt # → Should return empty (no long random strings) # Should contain safe identifiers only: grep "Request ID:" email_content.txt grep "Website:" email_content.txt # → Safe tracking without credentials ``` ## Testing Strategy ### 1. Security Review - [ ] Email content contains NO real API keys - [ ] Only safe display names in email - [ ] Request ID preserved for tracking - [ ] No sensitive data in email body ### 2. Functionality Validation - [ ] Email delivery still works - [ ] Request tracking functional - [ ] User experience unchanged - [ ] Admin can identify source website ### 3. Security Audit - [ ] mail-tester.com validation (content scan) - [ ] Email interception simulation - [ ] Log analysis for credential leaks - [ ] Multiple email provider testing ## Impact Assessment ### Immediate Benefits - ✅ **Eliminates API key exposure** in email content - ✅ **Reduces attack surface** significantly - ✅ **Maintains functionality** (tracking, identification) - ✅ **Improves professional appearance** (cleaner emails) ### Risk Mitigation - ✅ **No credential exposure** via email interception - ✅ **Safe email forwarding** (no sensitive data) - ✅ **Secure mail server storage** (no plaintext credentials) - ✅ **Audit-trail compliance** (no sensitive data in logs) ## Priority Justification **Why High Priority:** - **Security-Critical**: Real credentials exposed in plaintext - **Easy Fix**: Simple code change, low implementation risk - **High Impact**: Eliminates major security vulnerability - **Production Active**: Issue exists in live production system ## Success Criteria ### Before Fix (Vulnerable) ``` Website: Dragons@Work Website Production (daw_f8k2m9xp7q3n6w5z8c1v4b8j0s9e2r5t) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ EXPOSED API KEY = SECURITY RISK ``` ### After Fix (Secure) ``` Website: Dragons@Work Website Production ^^^^^^^^ SAFE - NO CREDENTIALS ``` ## Additional Security Considerations ### 1. Logging Review - Review furt logs for API key exposure - Ensure request logs don't contain credentials - Implement log sanitization if needed ### 2. Historical Email Audit - Check if previous emails contained API keys - Consider API key rotation if exposure confirmed - Review mail server logs for credential storage ### 3. Future Prevention - Code review checklist: "No credentials in user-facing content" - Automated testing for credential exposure - Security scanning in CI/CD pipeline ## Files Involved - `src/smtp.lua` (primary fix location) - `docs/security.md` (add security guidelines) - `tests/security_test.lua` (credential leak testing) ## Estimated Effort - **Fix Implementation**: 15 minutes - **Testing & Validation**: 30 minutes - **Security Review**: 15 minutes - **Total**: ~1 hour **Simple change, massive security improvement.**

michael added the

labels 2025-09-10 21:21:48 +02:00

michael changed title from ~~🚨 Security: Remove real API key exposure from email content~~ to Remove real API key exposure from email content

2025-09-10 21:23:07 +02:00

michael commented

2025-09-10 21:24:45 +02:00

Author

Owner

Korrekte Priorisierung
Nicht mehr: type/security,priority/high
Sondern: type/enhancement,priority/medium
Begründung:

✅ Sicherheitsarchitektur funktioniert (IP + Empfänger-Restriction)
✅ Code-Quality-Issue - sauberer ohne API-Key in Mails
✅ Professional Appearance - cleaner E-Mail-Format
✅ Best-Practice - keine Credentials in User-Content

Medium Priority = Richtig:

Sollte gefixt werden (unschön)
Nicht kritisch/urgent (sicher)
Nächste Development-Session (nicht Hotfix)

Korrekte Priorisierung Nicht mehr: type/security,priority/high Sondern: type/enhancement,priority/medium Begründung: ✅ Sicherheitsarchitektur funktioniert (IP + Empfänger-Restriction) ✅ Code-Quality-Issue - sauberer ohne API-Key in Mails ✅ Professional Appearance - cleaner E-Mail-Format ✅ Best-Practice - keine Credentials in User-Content Medium Priority = Richtig: Sollte gefixt werden (unschön) Nicht kritisch/urgent (sicher) Nächste Development-Session (nicht Hotfix)

michael added reference main

2025-09-10 21:25:29 +02:00