Pentest KRITISCH: Backup-Restore braucht Confirm-Body

POST /api/settings/backup/:name/restore startete bei leerem Body
sofort den destruktiven Restore. Im Unterschied zu /factory-reset
fehlte der Magic-String-Confirm-Check, sodass ein versehentlicher
Re-Fire (Doppelklick, Browser-Tab-Replay, eingeloggter Admin auf
bösartiger Drittseite) die komplette DB stillschweigend
überschreiben konnte.

Fix: gleicher Defensive-Pattern wie factoryReset – Body muss
{ "confirm": "RESTORE-BESTAETIGT" } enthalten, sonst 400. Der
Magic-String ist absichtlich ein einzigartiges Token (kein Boolean),
damit kein Auto-JSON-Tooling/Replay aus Versehen triggern kann.

Frontend-API-Client setzt das Token im Body automatisch – der
existierende Bestätigungs-Dialog im UI bleibt UX-mäßig unverändert.

Live-verifiziert:
- leerer Body → 400
- { confirm: "ja" } → 400
- { confirm: "RESTORE-BESTAETIGT" } → 200, Restore läuft

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

backend/src/controllers/backup.controller.ts

@@ -184,6 +184,19 @@ export async function restoreBackup(req: Request, res: Response) {
     return res.status(400).json({ error: 'Ungültiger Backup-Name' });
   }
 
+  // Pflicht-Confirm im Body, gleiche Defensive wie factoryReset.
+  // Pentest 2026-05-19 (KRITISCH): leerer POST-Body löste vorher
+  // sofort den destruktiven Restore aus – ein versehentlicher
+  // Re-Fire (Browser-Tab, CSRF auf eingeloggten Admin, doppelter
+  // Klick) konnte die DB ungewollt überschreiben. Der String ist
+  // bewusst ein unique Magic-Value, kein Boolean.
+  const confirm = (req.body && req.body.confirm) ? String(req.body.confirm) : '';
+  if (confirm !== 'RESTORE-BESTAETIGT') {
+    return res.status(400).json({
+      error: 'Bestätigung fehlt. Body muss { "confirm": "RESTORE-BESTAETIGT" } enthalten.',
+    });
+  }
+
   const capture = startLogCapture();
   try {
     const result = await backupService.restoreBackup(name);