Bug #330
offen[Bugsink] DateMalformedStringException: Failed to parse time string (2026-1 OR 144=(SELECT 144 FROM PG_SLEEP(15))---01-01) at position 7 (O): The timezone coul…
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/490b7124-ef51-460b-9de6-f03f708e33a9/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
DateMalformedStringException: Failed to parse time string (2026-1 OR 144=(SELECT 144 FROM PG_SLEEP(15))---01-01) at position 7 (O): The timezone coul…
Automatisch erstellt durch n8n
KI-Analyse:
Analyse des Fehlers¶
1. Ursache identifizieren¶
Der Fehler ist eine SQL-Injection-Attacke, die über einen manipulierten HTTP-Header- oder Request-Parameter in einen Datum-Parsing-Kontext von PHP eingespeist wurde.
Der zu parseende String lautet:
2026-01 OR 144=(SELECT 144 FROM PG_SLEEP(15))---01-01
Analyse:
-
2026-01...-01-01– Der Angreifer hat ein scheinbar gültiges Datumsformat konstruiert -
OR 144=(SELECT 144 FROM PG_SLEEP(15))– Klassische PostgreSQL-basierte SQL-Injection, versucht überPG_SLEEP(15)eine Zeitverzögerung (Blind SQL Injection) zu erzeugen -
position 7 (O)– PHP versucht den String als Datum zu parsen und scheitert an der Position 7 (dem Leerzeichen/OvonOR)
Was passiert: Ein HTTP-Header oder Request-Parameter (wahrscheinlich der Host-Header, gegebenenfalls ein Datum-Header) wird ohne ausreichende Validierung/Sanitization an eine DateTime-Funktion weitergegeben. Der manipulierte Wert wird im TYPO3 Core von der VerifyHostHeader-Middleware (Zeile 55) verarbeitet.
2. Fix (konkret)¶
| Schritte | Beschreibung |
|---|---|
| Sofortig | TYPO3 Core auf die neueste Version updaten – prüfen ob ein Security Patch (z.B. DSGVO/CVE) verfügbar ist |
| Eingabevalidierung | Alle HTTP-Header-Werte (besonders Host, Date) vor jeglicher Verarbeitung mit einem strengen Regex validieren (z.B. ^[a-zA-Z0-9\.\-]+$ für Host-Header) |
| Type-Hinting | Den Datumsparameter strikt typisieren – niemals Roh-HTTP-Header direkt an DateTime::createFromFormat() oder new DateTime() übergeben |
| Security | PostgreSQL pg_sleep() bestätigt, dass der Angriff auf die Datenbank abzielt → Prepared Statements prüfen und sicherstellen, dass keine dynamischen SQL-Abfragen mit User-Input erstellt werden |
| WAF/IPS | Einen Web Application Firewall (WAF) installieren, um PG_SLEEP, OR 1=1-ähnliche Patterns automatisch zu blockieren |
| Header-Whitelist | In typo3/AdditionalConfiguration.php oder Site-Configuration nur erlaubte Header-Felder whitelisten |
Konkreter Code-Fix (Beispiel):
// VOR (verwundbar):
$date = new DateTime($rawHeaderValue);
// NACH (sicher):
if (!preg_match('/^\d{4}-\d{2}-\d{2}[T ]\d{2}:\d{2}:\d{2}$/', $rawHeaderValue)) {
throw new \InvalidArgumentException('Invalid date format');
}
$date = new DateTime($rawHeaderValue);
3. Betroffene TYPO3 Extension¶
Hauptbetroffene Komponente: typo3/cms-core – spezifisch:
-
/vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php(Zeile 55) /vendor/typo3/cms-core/Classes/Http/AbstractApplication.php
Wahrscheinlich zusätzlich betroffene eigene Extension: Eine eigene/custom TYPO3-Extension, die HTTP-Header- oder Request-Daten ohne Validierung an Datum-Funktionen weitergibt. Falls vorhanden, müsste der Site-Handler oder ein PageRenderer-Plugin überprüft werden.
Hinweis: Ohne Kenntnis der installierten Drittanbieter-Extensions ist es möglich, dass eine spezifische Extension (z.B. eine News- oder Event-Extension mit Datumssuchen) den Einfallspunkt darstellt.
4. Confidence¶
| Aspekt | Bewertung |
|---|---|
| SQL-Injection-Erkennung |
100% – Die PG_SLEEP(15)-Syntax ist eindeutig |
| TYPO3 Core als Angriffsvektor | 90% – Stacktrace bestätigt Core-Middleware |
| Exakte betroffene Extension | 70% – Kann ohne vollständigen Projektcode nicht zu 100% bestimmt werden |
| Empfohlener Fix (Validierung) | 95% – Standard-Praxis für diese Angriffsart |
Gesamte Confidence: 85%
⚠️ Zusammenfassung¶
Dies ist eine aktive SQL-Injection-Attacke gegen die PostgreSQL-Datenbank, bei der der Angreifer versucht, über einen manipulierten Zeit-/Datums-String (in Kombination mit PG_SLEEP) eine Blind SQL Injection durchzuführen. Der Fehler selbst (DateMalformedStringException) ist nur die sichtbare Fehlermeldung – die echte Gefahr ist die SQL-Injection, die potenziell Daten abfließen oder die Datenbank kompromittieren kann. Sofortiger Patch und Sicherheitsüberprüfung sind erforderlich.
Nichts anzuzeigen