security: CRITICAL IDOR-Fix auf Stressfrei-Email-Sub-Routes

Pentest hat einen echten Credential-Exfiltration-Angriff erfolgreich
durchgespielt: als Portal-User von Kunde A komplette Klartext-IMAP/SMTP-
Zugangsdaten der Mailbox von Kunde B abgreifbar.

Root Cause: GET /api/stressfrei-emails/:id hatte canAccessStressfreiEmail-
Check, ALLE 8 Sub-Endpoints unter :id/* hatten nur `authenticate +
requirePermission('customers:read')` — was jeder Portal-User de facto hat.

Betroffene Controller (alle gefixt mit canAccessStressfreiEmail als erster
Zeile):

stressfreiEmail.controller.ts:
- updateEmail (PUT /:id)
- deleteEmail (DELETE /:id)
- resetPassword (POST /:id/reset-password)

cachedEmail.controller.ts:
- getMailboxCredentials (GET /:id/credentials) ← KRITISCHSTER, lieferte
  Klartext-IMAP/SMTP-Passwort + Server-Daten der fremden Mailbox
- getFolderCounts (GET /:id/folder-counts)
- syncAccount (POST /:id/sync)
- sendEmailFromAccount (POST /:id/send) — fremde Mailbox zum Versand
  missbrauchbar
- enableMailbox (POST /:id/enable-mailbox)
- syncMailboxStatus (POST /:id/sync-mailbox-status)

Security-Monitor: canAccessResourceByCustomerId emittiert bei jedem
Fehlversuch ein ACCESS_DENIED MEDIUM-Event. Threshold-Detection erzeugt
bei >5 Versuchen in 5 min ein CRITICAL SUSPICIOUS-Event + Sofort-Alert.

Live-verifiziert (Portal-User Kunde A versucht Email-ID von Kunde B):
- alle 8 Sub-Routes → HTTP 403
- eigene Email-ID → 200/400 (Ownership-Check OK)
- 8× ACCESS_DENIED MEDIUM im Security-Monitor

Doku in docs/SECURITY-HARDENING.md als Runde 13.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-16 17:47:54 +02:00
parent 72f7a9dbdb
commit 08310ac302
4 changed files with 108 additions and 11 deletions
@@ -22,6 +22,7 @@ import {
canAccessCustomer,
canAccessContract,
canAccessCachedEmail,
canAccessStressfreiEmail,
} from '../utils/accessControl.js';
// ==================== E-MAIL LIST ====================
@@ -214,9 +215,10 @@ export async function unassignFromContract(req: Request, res: Response): Promise
}
// E-Mail-Anzahl pro Ordner für ein Konto
export async function getFolderCounts(req: Request, res: Response): Promise<void> {
export async function getFolderCounts(req: AuthRequest, res: Response): Promise<void> {
try {
const stressfreiEmailId = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, stressfreiEmailId))) return;
const counts = await cachedEmailService.getFolderCountsForAccount(stressfreiEmailId);
@@ -250,9 +252,10 @@ export async function getContractFolderCounts(req: Request, res: Response): Prom
// ==================== SYNC & SEND ====================
// E-Mails für ein Konto synchronisieren (INBOX + SENT)
export async function syncAccount(req: Request, res: Response): Promise<void> {
export async function syncAccount(req: AuthRequest, res: Response): Promise<void> {
try {
const stressfreiEmailId = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, stressfreiEmailId))) return;
const fullSync = req.query.full === 'true';
// Synchronisiert sowohl INBOX als auch SENT
@@ -292,9 +295,10 @@ function hasCRLF(value: unknown): boolean {
}
// E-Mail senden
export async function sendEmailFromAccount(req: Request, res: Response): Promise<void> {
export async function sendEmailFromAccount(req: AuthRequest, res: Response): Promise<void> {
try {
const stressfreiEmailId = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, stressfreiEmailId))) return;
const { to, cc, subject, text, html, inReplyTo, references, attachments, contractId } = req.body;
// Header-Injection (CRLF) in Empfänger/Betreff ablehnen
@@ -624,9 +628,10 @@ export async function getMailboxAccounts(req: Request, res: Response): Promise<v
}
// Mailbox nachträglich aktivieren
export async function enableMailbox(req: Request, res: Response): Promise<void> {
export async function enableMailbox(req: AuthRequest, res: Response): Promise<void> {
try {
const id = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, id))) return;
const result = await stressfreiEmailService.enableMailbox(id);
@@ -649,9 +654,10 @@ export async function enableMailbox(req: Request, res: Response): Promise<void>
}
// Mailbox-Status mit Provider synchronisieren
export async function syncMailboxStatus(req: Request, res: Response): Promise<void> {
export async function syncMailboxStatus(req: AuthRequest, res: Response): Promise<void> {
try {
const id = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, id))) return;
const result = await stressfreiEmailService.syncMailboxStatus(id);
@@ -697,9 +703,13 @@ export async function getThread(req: Request, res: Response): Promise<void> {
}
// Mailbox-Zugangsdaten abrufen (IMAP/SMTP)
export async function getMailboxCredentials(req: Request, res: Response): Promise<void> {
export async function getMailboxCredentials(req: AuthRequest, res: Response): Promise<void> {
try {
const id = parseInt(req.params.id);
// Ownership-Check: ohne diesen Check konnte ein Portal-Kunde mit
// bekannter Stressfrei-Email-ID die kompletten IMAP/SMTP-Credentials
// eines anderen Kunden abrufen (IDOR). Pentest-Finding 2026-05-XX.
if (!(await canAccessStressfreiEmail(req, res, id))) return;
// StressfreiEmail laden
const stressfreiEmail = await stressfreiEmailService.getEmailWithMailboxById(id);
@@ -68,9 +68,11 @@ export async function createEmail(req: Request, res: Response): Promise<void> {
}
}
export async function updateEmail(req: Request, res: Response): Promise<void> {
export async function updateEmail(req: AuthRequest, res: Response): Promise<void> {
try {
const email = await stressfreiEmailService.updateEmail(parseInt(req.params.id), req.body);
const emailId = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, emailId))) return;
const email = await stressfreiEmailService.updateEmail(emailId, req.body);
await logChange({
req, action: 'UPDATE', resourceType: 'StressfreiEmail',
resourceId: email.id.toString(),
@@ -85,9 +87,10 @@ export async function updateEmail(req: Request, res: Response): Promise<void> {
}
}
export async function deleteEmail(req: Request, res: Response): Promise<void> {
export async function deleteEmail(req: AuthRequest, res: Response): Promise<void> {
try {
const emailId = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, emailId))) return;
await stressfreiEmailService.deleteEmail(emailId);
await logChange({
req, action: 'DELETE', resourceType: 'StressfreiEmail',
@@ -142,9 +145,11 @@ export async function syncForwarding(req: AuthRequest, res: Response): Promise<v
}
}
export async function resetPassword(req: Request, res: Response): Promise<void> {
export async function resetPassword(req: AuthRequest, res: Response): Promise<void> {
try {
const result = await stressfreiEmailService.resetMailboxPassword(parseInt(req.params.id));
const emailId = parseInt(req.params.id);
if (!(await canAccessStressfreiEmail(req, res, emailId))) return;
const result = await stressfreiEmailService.resetMailboxPassword(emailId);
if (!result.success) {
res.status(400).json({
success: false,
+59
View File
@@ -271,6 +271,65 @@ gering, aber Audit-Bewertung fordert konsistente Header-Hygiene.
nachvollziehbar, wer wann welches Passwort eingesehen hat
(DSGVO + Insider-Threat).
### Runde 13 KRITISCH: IDOR auf Stressfrei-Email-Sub-Routes (Live-Pentest-Fund)
Externer Pentest hat einen echten Credential-Exfiltration-Angriff erfolgreich
durchgespielt: **als Portal-User von Kunde A komplette IMAP/SMTP-Klartext-
Credentials von Kunde B abgreifen können**.
**Angriffspfad:**
1. Portal-Login als Kunde A
2. `/api/stressfrei-emails/{id}` GET unterschied saubere Antworten:
- „E-Mail-Konto nicht gefunden" (ID existiert nicht)
- „Kein Zugriff auf diese Kundendaten" (ID existiert, gehört anderem)
→ Information-Disclosure: Existenz von IDs durchprobierbar
3. `/api/stressfrei-emails/{id}/credentials` GET ohne Ownership-Check →
IMAP/SMTP-Server, Username und **Klartext-Passwort** der fremden Mailbox
**Root Cause:** der Haupt-Endpoint `GET /:id` hatte `canAccessStressfreiEmail`,
die 8 Sub-Endpoints unter `:id/*` hatten **alle keinen** Ownership-Check —
nur `authenticate + requirePermission('customers:read')`, was jeder Portal-User
hat.
**Betroffene Endpoints (alle gefixt):**
- `GET /:id/credentials` ← **der kritische** (Klartext-Passwort + IMAP/SMTP)
- `GET /:id/folder-counts`
- `POST /:id/sync`
- `POST /:id/send`
- `POST /:id/enable-mailbox`
- `POST /:id/sync-mailbox-status`
- `POST /:id/reset-password`
- `PUT /:id` (updateEmail im stressfreiEmail.controller)
- `DELETE /:id` (deleteEmail)
`canAccessStressfreiEmail(req, res, emailId)` als erste Zeile in jedem
Controller. `canAccessResourceByCustomerId` emittiert bei Fehlversuch
automatisch ein `ACCESS_DENIED MEDIUM`-Event ins Security-Monitoring → bei
>5 Versuchen in 5 min wird ein `CRITICAL SUSPICIOUS`-Event erzeugt + Alert
verschickt.
**Live-verifiziert (Portal-User Kunde A versucht Email-ID von Kunde B):**
| Endpoint | Vorher | Nachher |
| --- | --- | --- |
| `GET /:id/credentials` | 🚨 **200 mit Klartext-Passwort** | ✅ 403 |
| `GET /:id/folder-counts` | 🚨 200 | ✅ 403 |
| `POST /:id/sync` | 🚨 200 | ✅ 403 |
| `POST /:id/send` | 🚨 fremde Mailbox zum Versand missbrauchbar | ✅ 403 |
| `POST /:id/enable-mailbox` | 🚨 200 | ✅ 403 |
| `POST /:id/sync-mailbox-status` | 🚨 200 | ✅ 403 |
| `POST /:id/reset-password` | 🚨 fremdes Mailbox-Passwort zurücksetzbar | ✅ 403 |
| `POST /:id/sync-forwarding` | (vorher schon gefixt) | ✅ 403 |
| `PUT /:id` | 🚨 fremde Adresse änderbar | ✅ 403 |
| `DELETE /:id` | 🚨 fremde Adresse löschbar | ✅ 403 |
| Eigene Email-ID | (legitim) | ✅ 200/400 (durch) |
| Security-Monitor | | 8× `ACCESS_DENIED MEDIUM` geloggt ✅ |
**Lehre:** wenn ein Haupt-Endpoint `:id` einen Ownership-Check hat, müssen
**alle** Sub-Endpoints unter `:id/*` denselben Check haben. Eine fehlende
Zeile am Anfang eines Sub-Controllers reicht für komplette Credential-
Exfiltration über das Customer-Portal.
### Runde 12 JWT raus aus localStorage (XSS-Resistenz)
Externer Pentest: "JWT in `localStorage` (MITTEL)". Bei einer XSS-Lücke
+23
View File
@@ -97,6 +97,29 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
## ✅ Erledigt
- [x] **🚨 KRITISCH: IDOR auf Stressfrei-Email-Sub-Routes (Pentest-Fund)**
- **Realer Angriff erfolgreich durchgespielt**: Portal-User konnte über
`/api/stressfrei-emails/{id}/credentials` die kompletten Klartext-
IMAP/SMTP-Zugangsdaten der Mailbox eines anderen Kunden abrufen.
- **Root Cause**: der Haupt-Endpoint `GET /:id` hatte
`canAccessStressfreiEmail`-Check, die **8 Sub-Endpoints** unter
`:id/*` hatten alle KEINEN Ownership-Check (nur `authenticate +
requirePermission('customers:read')`, was Portal-User von Haus aus
haben).
- **Fix**: `canAccessStressfreiEmail(req, res, id)` als erste Zeile in
allen 9 betroffenen Controllern: `getMailboxCredentials`,
`getFolderCounts`, `syncAccount`, `sendEmailFromAccount`,
`enableMailbox`, `syncMailboxStatus`, `resetPassword`, `updateEmail`,
`deleteEmail`.
- **Security-Monitor**: `canAccessResourceByCustomerId` emittiert
bei jedem Fehlversuch automatisch ein `ACCESS_DENIED MEDIUM`-Event
→ Threshold-Detection (>5 in 5 min) erzeugt `CRITICAL SUSPICIOUS` +
Sofort-Alert.
- **Live-verifiziert**: Portal-User Kunde A probiert Email-ID von
Kunde B durch alle 8 Sub-Routes → **alle 8× HTTP 403**, eigene
Email-ID kommt sauber durch (200/400), 8× `ACCESS_DENIED`-Events
im Security-Monitor.
- [x] **🛡️ JWT-Tokens raus aus localStorage Refresh-Cookie-Pattern**
- Pentest-Finding „JWT in localStorage (MITTEL)": bei XSS könnte JS
den Token klauen + alle Anbieter-Credentials abrufen. Lösung: