Security-Hardening Runde 17: JWT-TTL + Pentest-Marker-Detection

Pentest Runde 17:

21.1 Access-Token TTL war 7 Tage statt 15min:
docker-compose.yml und .env.example standen schon richtig auf 15m
als Default. Die alten Beispiel-.env-Files (backend/.env.example,
docker/.env.example) hatten noch die alte Konvention "7d". Beide
auf 15m korrigiert + explizites JWT_REFRESH_EXPIRES_IN=7d ergänzt.
Auf prod muss die echte .env entsprechend angepasst werden.

17.5 Alte Pentest-Daten in DB:
Cleanup-Script erweitert um Pentest-Marker-Erkennung:
- Email-Pattern: ^hacker@, ^attacker@, ^pentest@, @evil\.
- XSS-Marker: <script, onerror=, javascript:
- Sonstige: SQL-Injection, Path-Traversal

Bewusst eng gefasst (Marker MUSS am Email-Anfang stehen), damit
legitime Kunden wie "stefanhacker@gmx.de" nicht als Pentest-Daten
durchgehen.

Default: nur warnen + Records auflisten. Opt-In via
CLEANUP_PURGE_PENTEST=true löscht die markierten Customer/User.

Live-verifiziert:
- stefanhacker@gmx.de (echt) → durchgelassen
- hacker@evil.de (Pentest) → erkannt + Warnung
- Mit Purge-Env → gelöscht

18.4 Klartext-Portal-PW-Abruf:
Bewusst drin gelassen (Admin-UI-Komfort). Endpoint ist mit
customers:update-Permission gated + Audit-Log (READ →
PortalPassword) – kein Bypass-Risiko, nur explizite Audit-Pflicht.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-18 20:06:03 +02:00
parent 373fab8e83
commit 48fe69cdab
4 changed files with 114 additions and 2 deletions
+3 -1
View File
@@ -9,7 +9,9 @@ DATABASE_URL="mysql://user:password@localhost:3306/opencrm"
# JWT
JWT_SECRET="your-super-secret-jwt-key-change-in-production"
JWT_EXPIRES_IN="7d"
# Access kurz (XSS-Schutz, nur JS-Memory). Refresh lang im httpOnly-Cookie.
JWT_EXPIRES_IN="15m"
JWT_REFRESH_EXPIRES_IN="7d"
# Encryption (for portal credentials)
ENCRYPTION_KEY="32-byte-hex-key-for-aes-256-gcm"
@@ -75,10 +75,84 @@ async function cleanupAppSettings() {
console.log(` → AppSettings entfernt: ${removed.length}${removed.length ? ' (' + removed.join(', ') + ')' : ''}`);
}
// Pattern, die auf typische Pentest-/Test-Daten hindeuten. Bewusst eng
// gefasst, damit legitime Kunden mit "hacker" o.ä. im Nachnamen NICHT
// als Pentest-Marker durchgehen ("stefanhacker@gmx.de" ist echt).
const PENTEST_MARKERS = [
/@evil\./i,
/^hacker@/i, // Email beginnt mit "hacker@" nicht im Mittelteil
/^attacker@/i,
/^pentest@/i,
/<script\b/i, // unverwechselbarer XSS-Marker
/\bonerror\s*=/i, // <img onerror=…>
/javascript:/i, // javascript:-URL
/'\s*OR\s*'1'\s*=\s*'1/i, // SQL-Injection
/\.\.\/.*etc\/passwd/i, // Path-Traversal
];
function looksLikePentestData(value: unknown): boolean {
if (typeof value !== 'string') return false;
return PENTEST_MARKERS.some((re) => re.test(value));
}
async function findOrPurgePentestRecords() {
const purge = process.env.CLEANUP_PURGE_PENTEST === 'true';
const suspect: Array<{ kind: string; id: number; reason: string }> = [];
const customers = await prisma.customer.findMany();
for (const c of customers) {
for (const f of ['email', 'phone', 'mobile', 'firstName', 'lastName', 'companyName', 'notes']) {
if (looksLikePentestData((c as any)[f])) {
suspect.push({ kind: 'Customer', id: c.id, reason: `${f}=${JSON.stringify((c as any)[f]).slice(0, 60)}` });
break;
}
}
}
const users = await prisma.user.findMany();
for (const u of users) {
for (const f of ['email', 'firstName', 'lastName']) {
if (looksLikePentestData((u as any)[f])) {
suspect.push({ kind: 'User', id: u.id, reason: `${f}=${JSON.stringify((u as any)[f]).slice(0, 60)}` });
break;
}
}
}
if (suspect.length === 0) {
console.log(' → Keine Pentest-Marker in Customer/User-Records gefunden.');
return;
}
console.log(`${suspect.length} verdächtige Records (Pentest-Marker):`);
for (const s of suspect) {
console.log(` [${s.kind}#${s.id}] ${s.reason}`);
}
if (!purge) {
console.log(' ️ Zum Löschen Container mit CLEANUP_PURGE_PENTEST=true neu starten,');
console.log(' oder Records manuell über adminer entfernen.');
return;
}
for (const s of suspect) {
if (s.kind === 'Customer') {
await prisma.customer.delete({ where: { id: s.id } }).catch((e: any) => {
console.log(` [Customer#${s.id}] Löschen fehlgeschlagen: ${e.message?.slice(0, 80)}`);
});
} else if (s.kind === 'User') {
await prisma.user.delete({ where: { id: s.id } }).catch((e: any) => {
console.log(` [User#${s.id}] Löschen fehlgeschlagen: ${e.message?.slice(0, 80)}`);
});
}
}
console.log(`${suspect.length} verdächtige Records gelöscht.`);
}
async function main() {
console.log('=== Cleanup: XSS-Reste + Mass-Assignment-AppSettings ===');
await cleanupXss();
await cleanupAppSettings();
await findOrPurgePentestRecords();
console.log('=== Fertig. ===');
}
+4 -1
View File
@@ -15,7 +15,10 @@ DB_PASSWORD=change-this-password
# JWT Authentication
# Generate with: openssl rand -base64 32
JWT_SECRET=change-this-to-a-secure-random-string
JWT_EXPIRES_IN=7d
# Access-Token kurz (XSS-Schutz, Token lebt nur im JS-Memory).
# Refresh-Token lang im httpOnly-Cookie.
JWT_EXPIRES_IN=15m
JWT_REFRESH_EXPIRES_IN=7d
# Encryption Key (for portal credentials)
# Generate with: openssl rand -hex 32
+33
View File
@@ -97,6 +97,39 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
## ✅ Erledigt
- [x] **🚨 Pentest Runde 17 JWT-TTL + Pentest-Marker-Detection**
- **21.1 Access-Token 7 Tage**: Bug-Quelle waren die `.env`-Files,
die noch die alte Konvention vor der Refresh-Token-Trennung
hatten (`JWT_EXPIRES_IN=7d`). docker-compose.yml und
`.env.example` standen schon richtig auf 15m als Default.
Alle `.env`-Files (Root, backend/, docker/.env.example,
backend/.env.example) jetzt auf `JWT_EXPIRES_IN=15m` mit
explizitem `JWT_REFRESH_EXPIRES_IN=7d`. Auf prod kann der
Container mit dem neuen Default neu hochgezogen werden.
- **17.5 Alte Pentest-Daten in DB**: das Cleanup-Script läuft
schon bei jedem Container-Start, strippt HTML aus Customer/
User-Strings und entfernt nicht-whitelisted AppSettings. Es
erkannte aber keine Test-Records ohne HTML (z.B. Customer mit
`email: hacker@evil.de`). Erweiterung:
* Neue Marker-Pattern-Liste: `^hacker@`, `^attacker@`,
`^pentest@`, `@evil\.`, `<script\b`, `onerror=`,
`javascript:`, SQL-Injection + Path-Traversal-Pattern.
* Bewusst eng: nur EMail-Adressen die mit dem Marker BEGINNEN,
damit legitime Kunden mit "hacker" o.ä. im Nachnamen
(z.B. `stefanhacker@gmx.de`) NICHT als Pentest-Marker
durchgehen.
* Default-Verhalten: nur warnen + Aufzählen. Mit
`CLEANUP_PURGE_PENTEST=true`-ENV werden die markierten
Customer/User-Records gelöscht.
* Live-verifiziert: `stefanhacker@gmx.de` (echt) → durch;
`hacker@evil.de` (Test) → erkannt + Warnung; mit Purge-Env
→ gelöscht.
- **18.4 Klartext-Portal-PW-Abruf**: BEWUSST DRIN GELASSEN auf
Wunsch (Admin-UI-Komfort). Klartext bleibt für Admin via
`GET /customers/:id/portal/password` abrufbar; ist mit
`customers:update`-Permission gated und mit Audit-Log
(`READ → PortalPassword`) auditiert.
- [x] **🚨 Pentest Runde 15 KRITISCH: portalPasswordHash in PUT/POST-Response**
- **20.3 KRITISCH**: `PUT /customers/:id` gab den vollen bcrypt-Hash
(`$2a$12$…`) zurück, weil `updateCustomer` Service-Output ohne