Security-Hardening Runde 11: Pentest Runde 7 (Portal-PW + Download-Tokens)

Hit-List vom Pentester abgearbeitet. Hauptpunkte:

1) Contract/Mail-Credentials (password/internet/sip/simcard, mailbox/send/
   reset-password): ALLE bereits durch canAccess* gesichert, keine Lücke.

2) GET /customers/:id/portal/password (Klartext-Portal-PW-Abruf):
   fehlender canAccessCustomer-Check ergänzt. Defense in depth gegen
   versehentliche customers:update-Permission an Portal/eingeschränkte
   Mitarbeiter.

3) Admin-Endpoints (factory-reset, developer/*, audit-logs/rehash,
   audit-logs/customer): durch admin-Permissions geschützt – Portal-User
   haben diese nicht.

4) Token-in-URL (NIEDRIG): Langlebige Access-JWTs landeten als ?token= in
   URLs für iframe-PDFs, Audit-Export-Window etc. → nginx-Logs +
   Browser-History + Referer.
   Lösung: kurzlebige Download-Tokens.
   - signDownloadToken() liefert JWT mit type='download', exp=60s
   - Auth-Middleware akzeptiert type='download' AUSSCHLIESSLICH via
     ?token=, niemals als Bearer-Header
   - POST /api/auth/download-token Endpoint (authenticated)
   - Frontend: authApi.getDownloadToken() utility
   - 4 Stellen migriert: AuditLog-Export, PdfTemplate-Preview-iframe,
     PdfTemplate-Generate, ContractDetail-PDF-Generate (2x),
     Portal-Privacy-PDF
   - fileUrl/getAttachmentUrl sind synchron + breit gestreut – Migration
     bleibt für Folge-PR

Live-verifiziert:
- Download-Token: 1773 Zeichen, type=download, exp-iat=60s
- als Header → 401 (Falscher Token-Typ), als ?token= → 200
- portal-user (Customer 3) auf customers/2/portal/password → 403

Rate-Limiter-Check: express-rate-limit Fixed-Window, kein Reset bei jedem
Request (Pentester-Klage „Fenster reseted sich" stimmt mit dem Code nicht
überein – wahrscheinlich Retry-After-Misinterpretation). Kein Code-Bug
identifiziert; ggf. später Admin-Override-Endpoint nachrüsten.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

backend/src/middleware/auth.ts

@@ -13,12 +13,15 @@ export async function authenticate(
 
   // Token aus Header oder Query-Parameter (für Downloads)
   let token: string | null = null;
+  let tokenSource: 'header' | 'query' | null = null;
 
   if (authHeader && authHeader.startsWith('Bearer ')) {
     token = authHeader.split(' ')[1];
+    tokenSource = 'header';
   } else if (req.query.token && typeof req.query.token === 'string') {
     // Fallback für Downloads: Token als Query-Parameter
     token = req.query.token;
+    tokenSource = 'query';
   }
 
   if (!token) {
@@ -38,7 +41,19 @@ export async function authenticate(
     // Endpoint. Legacy-Tokens (vor der Refresh-Token-Einführung) haben kein
     // `type` und werden als Access akzeptiert, damit bestehende Sessions nicht
     // zwangsabgemeldet werden.
-    if (decoded.type && decoded.type !== 'access') {
+    if (decoded.type === 'refresh') {
+      res.status(401).json({ success: false, error: 'Falscher Token-Typ' });
+      return;
+    }
+    // Download-Tokens sind kurzlebig (60s) und dürfen NUR per `?token=`
+    // genutzt werden, NIE als Bearer-Header. Damit kann ein in einer URL
+    // geleakter Download-Token nicht für reguläre API-Aufrufe missbraucht
+    // werden (Pentest Runde 7 – NIEDRIG, Token-in-URL-Defense).
+    if (decoded.type === 'download' && tokenSource !== 'query') {
+      res.status(401).json({ success: false, error: 'Falscher Token-Typ' });
+      return;
+    }
+    if (decoded.type && decoded.type !== 'access' && decoded.type !== 'download') {
       res.status(401).json({ success: false, error: 'Falscher Token-Typ' });
       return;
     }