docs: Pentest-Runden 11 + 12 in SECURITY-HARDENING + README aktualisieren
SECURITY-HARDENING.md: - Runde 11 "Externer Pentest-Folge: Header-Hygiene + Klartext-Audit": HSTS-Doppel-Header weg, Cache-Control je nach Pfad differenziert, CSP No-Fallback-Direktiven + frame-ancestors auf 'self', BREACH- Mitigation via gzip off im Reverse-Proxy für /api/*, Server-/ X-Served-By-Banner entfernt, Audit-Log für die 6 Klartext-Passwort- Read-Endpoints (CRITICAL). - Runde 12 "JWT raus aus localStorage": Branchenstandard-Refresh-Cookie- Pattern für die SPA. Access-Token (15 min) nur in JS-Memory, Refresh-Token (7d) im httpOnly-Cookie. Auth-Middleware verweigert Refresh-Tokens als Bearer (type-Claim). Axios-Interceptor mit Single-Flight-Refresh-Retry. Tabelle der Live-Tests. README.md: - Tech-Stack-Auth-Zeile beschreibt jetzt die Access/Refresh-Architektur - .env-Beispiel: JWT_EXPIRES_IN=15m + neue JWT_REFRESH_EXPIRES_IN=7d - Production-Deployment-Hinweis: Frontend und API müssen über dieselbe Origin laufen (SameSite=Strict-Cookie), sonst funktioniert /auth/refresh cross-site nicht und User wird alle 15 min ausgeloggt Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -230,6 +230,87 @@ Nichts Kritisches mehr gefunden. Liefert noch:
|
||||
- **Concurrent Password-Reset Race**: Token wird nach erstem Confirm
|
||||
atomar gelöscht – zweiter Versuch findet keinen Token. ✅
|
||||
|
||||
### Runde 11 – Externer Pentest-Folge: Header-Hygiene + Klartext-Audit
|
||||
|
||||
Externer Pentest (testssl, ZAP, Nikto, Nuclei) gegen Prod-VM hat drei
|
||||
Klassen Defense-in-Depth-Findings rausgespült. Reale Ausnutzbarkeit jeweils
|
||||
gering, aber Audit-Bewertung fordert konsistente Header-Hygiene.
|
||||
|
||||
- **HSTS-Doppel-Header (18×)**: Nginx-Proxy-Manager (TLS-Terminierung) UND
|
||||
Helmet schickten beide `Strict-Transport-Security` → RFC-6797-Verletzung.
|
||||
Helmet's HSTS deaktiviert (`strictTransportSecurity: false`); der
|
||||
Reverse-Proxy übernimmt die Policy zentral am Edge.
|
||||
- **Cache-Control (~10×)**: `/api/*` → `no-store` (sensible JSON-Daten),
|
||||
SPA-HTML (`/`, `/sitemap.xml`, `/robots.txt`) → `no-store, must-revalidate`
|
||||
(sonst hängt der Browser nach Deploy an alter `index.html` fest),
|
||||
`/assets/*.{js,css}` → `public, max-age=31536000, immutable` (Vite-Bundles
|
||||
haben Content-Hash im Filename).
|
||||
- **CSP No-Fallback-Direktiven (2×)**: `worker-src`, `manifest-src`,
|
||||
`media-src` jetzt explizit auf `'self'`.
|
||||
- **CSP `frame-ancestors`**: war `'none'`, das blockt auch same-origin-iframes
|
||||
→ PDF-Vorschau im PDF-Template-Editor lädt nicht. Korrigiert auf
|
||||
`'self'` (eigene App darf eigene Resourcen embeden, externe Sites bleiben
|
||||
via `X-Frame-Options: SAMEORIGIN` weiter gesperrt).
|
||||
- **BREACH (CVE-2013-3587)**: testssl meldet "potentially VULNERABLE,
|
||||
gzip HTTP compression detected" – theoretischer Side-Channel-Angriff
|
||||
auf gzip-komprimierte HTTPS-Responses. Praktisch klein bei JWT-SPA (keine
|
||||
reflektierten Secrets im Response), Audit-Marker bleibt aber MEDIUM.
|
||||
Fix: gzip im Reverse-Proxy für `/api/*` deaktivieren (Custom-Location im
|
||||
NPM, Statische Assets bleiben weiter komprimiert). README dokumentiert
|
||||
Setup.
|
||||
- **`Server: openresty` + `x-served-by`-Banner**: am NPM via
|
||||
`more_clear_headers Server X-Served-By;` weg.
|
||||
- **Audit-Log für Klartext-Passwort-Reads**: Pentest fand "HOCH (post-auth):
|
||||
Klartext-Passwörter über API abrufbar" — reversible AES-256-GCM ist
|
||||
by-design für das Feature "Anbieter-Login anzeigen", aber **keiner** der
|
||||
sechs Endpoints (`PortalPassword`, `ContractPassword`, `SimCardCredentials`,
|
||||
`InternetCredentials`, `SipCredentials`, `MailboxCredentials`) schrieb
|
||||
bisher einen Audit-Log-Eintrag. Jetzt: `action: 'READ'` mit eigenem
|
||||
Resource-Type + `sensitivity: CRITICAL`, Label nennt explizit "Klartext
|
||||
… entschlüsselt" + Resource-ID. Damit ist im Audit-Log-Viewer jederzeit
|
||||
nachvollziehbar, wer wann welches Passwort eingesehen hat
|
||||
(DSGVO + Insider-Threat).
|
||||
|
||||
### Runde 12 – JWT raus aus localStorage (XSS-Resistenz)
|
||||
|
||||
Externer Pentest: "JWT in `localStorage` (MITTEL)". Bei einer XSS-Lücke
|
||||
irgendwo in der App wäre der Token JS-erreichbar → Angreifer könnte alle
|
||||
Anbieter-Credentials abrufen. Aktuell gibt's keinen bekannten XSS-Vektor
|
||||
(CSP `script-src 'self'`, React-DOM-Escaping, keine `dangerouslySetInnerHTML`
|
||||
außer in Admin-befüllten HTML-Templates), aber das Defense-in-Depth-Pattern
|
||||
gehört auf den SPA-Branchenstandard:
|
||||
|
||||
- **Access-Token**: 15 min Lifetime, lebt **nur im JavaScript-Memory**
|
||||
(Modul-State in `api.ts` + `AuthContext`). Kein `localStorage` mehr.
|
||||
- **Refresh-Token**: 7 Tage, im **httpOnly-Cookie** (`Secure` bei
|
||||
`HTTPS_ENABLED`, `SameSite=Strict`, `Path=/api/auth`). JS hat keinen
|
||||
Zugriff → XSS klaut **maximal** einen 15-min-Access-Token.
|
||||
- **POST `/api/auth/refresh`**: liest Cookie, gibt neuen Access aus, rotiert
|
||||
Refresh-Cookie. Prüft `tokenInvalidatedAt` (Logout/Rollenänderung =
|
||||
sofortige Invalidation aller Tokens, auch des Refresh).
|
||||
- **Auth-Middleware**: lehnt Refresh-Tokens (`type: 'refresh'`) als Bearer
|
||||
ab → 401 `"Falscher Token-Typ"`. Defense-in-Depth gegen Token-Confusion.
|
||||
- **Axios-Interceptor**: bei 401 → Single-Flight-Refresh-Retry. Original-Request
|
||||
wird transparent wiederholt; concurrent 401s teilen sich denselben
|
||||
Refresh-Aufruf.
|
||||
- **App-Start**: ruft `/auth/refresh` auf; wenn Cookie gültig → User
|
||||
automatisch eingeloggt, kein Re-Login nach Tab-Reload trotz
|
||||
memory-only Access-Token.
|
||||
- **Logout**: löscht Cookie + setzt `tokenInvalidatedAt` → auch parallele
|
||||
Sessions auf anderen Geräten sind ungültig.
|
||||
|
||||
Live-Tests (alle ✅):
|
||||
|
||||
| Test | Resultat |
|
||||
| --- | --- |
|
||||
| Login | Cookie `HttpOnly; SameSite=Strict; Path=/api/auth` gesetzt, Access-Token im Body |
|
||||
| API-Call mit Bearer | 200 |
|
||||
| API-Call ohne Bearer | 401 |
|
||||
| `/auth/refresh` mit Cookie | 200, rotiertes Cookie, neuer Access |
|
||||
| `/auth/refresh` ohne Cookie | 401 |
|
||||
| Refresh-Token als Bearer benutzt | 401 „Falscher Token-Typ" |
|
||||
| Logout → `/auth/refresh` | 401 (Cookie weg, tokenInvalidatedAt gesetzt) |
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Geprüft + sauber (kein Bug, aber explizit getestet)
|
||||
|
||||
Reference in New Issue
Block a user