Bug #345
offen[Bugsink] DateMalformedStringException: Failed to parse time string (2026-01i5R1Ctbv') OR 479=(SELECT 479 FROM PG_SLEEP(15))---01) at position 8 (5): Unexpecte…
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/9c959280-bdb9-4b54-bc4c-428e8cde913e/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
DateMalformedStringException: Failed to parse time string (2026-01i5R1Ctbv') OR 479=(SELECT 479 FROM PG_SLEEP(15))---01) at position 8 (5): Unexpecte…
Automatisch erstellt durch n8n
KI-Analyse:
Analyse des Fehlers¶
1️⃣ Hauptursache (Root Cause) ¶
Das TYPO3-System erhält einen benutzerdefinierten Wert, der als Datum interpretiert werden soll (z. B. ein Query-String-Parameter, ein POST-Feld oder ein Wert aus einem GET-Request).
Die Zeichenfolge wird direkt an eine PHP-Datetime-Parsing-Routine weitergegeben, ohne dass eine Eingabeprüfung, Typkonvertierung oder Formatsvalidierung erfolgt.
Der empfangene Wert lautet:
2026-01i5R1Ctbv') OR 479=(SELECT 479 FROM PG_SLEEP(15))---01)
- Der Teil
2026-01sieht wie ein gültiges ISO-Datum (YYYY-MM) aus. - Die Zeichenfolge nach dem Monatsanteil (
i5R1Ctbv') OR 479=(SELECT 479 FROM PG_SLEEP(15))---01)) enthält unerwartete Zeichen (i,5,R,C,t,b,v,', Space,OR, SQL-Anweisung usw.). - PHPs
DateTime::createFromFormat()(oder eine ähnliche TYPO3-Wrap-Routine) schlägt mit folgender Fehlermeldung fehl:
DateMalformedStringException: Failed to parse time string (…) at position 8 (5): Unexpected character
Ergebnis: Der Server stürzt mit einer ungefilterten, nativen PHP-Ausnahme ab, anstatt den Angriff zu blockieren, zu protokollieren und einen sicheren Fehler zu liefern.
2️⃣ Warum sieht das wie ein SQL-Injection-Angriff aus? ¶
DerPayload enthält das klassische Muster eines zeitbasierten Blind-SQL-Injection-Versuchs (OR 479=(SELECT 479 FROM PG_SLEEP(15))---).
Angreifer fügen solche Strings oft in allen Feldern ein, die später in eine Datenbankabfrage eingefügt werden könnten (z. B. WHERE date_column = ?).
Obwohl der Fehler ein Datums-Parsing-Problem ist, zeigt der Versuch, eine SQL-Injection einzufügen, dass der Angreifer versucht, möglicherweise schädliche Daten in jede Verarbeitungsstufe einzuschleusen.
3️⃣ Was müsste passieren, damit der Angriff erfolgreich ist? ¶
- Wenn der code, der die Zeichenfolge parst, ausfällt, wird das Anfrage-Lifecycle nie den DB-Zugriff erreichen → der SQL-Teil wird nie ausgeführt.
- Wenn die Validierung fehlt und der Wert später wieder in ein SQL-Query eingefügt wird, wäre die Injektion erfolgreich.
Spezifischer Fix (konkret)¶
| Schritt | Umsetzung | TYPO3-spezifische Hinweise |
|---|---|---|
| A. Validieren Sie die Eingabe an der Grenze | Validieren Sie alle Datumswerte bevor sie die Anwendung erreichen. Verwenden Sie einen strengen Validator (z. B. DateValidator aus TYPO3\CMS\Core\Validation\Validator\DateValidator). |
Erstellen Sie einen DataHandler- oder FormDataValidator, der DateTime::createFromFormat('Y-m-d', $input) verwendet und false zurückgibt, wenn die Zeichenfolge nicht übereinstimmt. |
| B. Erlauben Sie nur ein bekanntes Format | Akzeptieren Sie nur Y-m-d (oder Y-m-d H:i:s, je nach Anforderung) und verwerfen Sie alles, was zusätzliche Zeichen wie Buchstaben, Leerzeichen, Anführungszeichen, Bindestriche oder SQL-Schlüsselwörter enthält. |
Verwenden Sie if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $value)) { throw new ... }. |
| C. Verwenden Sie die TYPO3-Datentyp-Routinen | Anstatt die rohe PHP DateTime-Klasse zu verwenden, verwenden Sie TYPO3\CMS\Core\Type\DateTime::createFromString() (oder DateTime::createFromFormat). So erhalten Sie eine einheitliche Fehlerbehandlung und Internationalisierung. |
Beispiel:try {<br> $date = \TYPO3\CMS\Core\Type\DateTime::createFromString($input);<br>} catch (\InvalidArgumentException $e) {<br> // Verwerfen Sie die Anfrage / protokollieren Sie den Fehler<br>}
|
| D. Sichere Protokollierung und Fehlerbehandlung | Erfassen Sie den rohen Wert, den Zeitpunkt des Versuchs und die IP-Adresse des Angreifers in denTYPO3-Protokollen ($logger->warning(...)). Liefern Sie eine generische 400/500-Seite an den Client (kein Stack-Trace). |
Verwenden Sie \TYPO3\CMS\Core\Log\Logger::warning('DateMalformedStringException', ['value' => $input, 'ip' => $request->getServerParams()['REMOTE_ADDR']]). |
| E. Oberflächenvalidierung auf Controller-Ebene | Fügen Sie validate zu Extbase-Repositories oder Formulardaten hinzu. Beispiel ValidationProvider in einem Extbase-Model: protected $validatorClass = 'TYPO3\\CMS\\Extbase\\Validation\Validator\DateValidator';
|
So wird die Validierung erzwungen, auch wenn ein Extension-Entwickler den Wert anders verwendet. |
| F. Fallback für beschädigte Daten | Falls ein Wert als ungültig markiert wird, behandeln Sie ihn wie ein nicht vorhandenes Feld: ignorieren Sie ihn oder verwenden Sie einen sicheren Standardwert (z. B. null). |
„Wenn Sie ein optionales Datum benötigen, überspringen Sie es einfach, anstatt abzustürzen.“ |
| G. Überprüfen Sie alle Datumsquellen | Nicht nur URL-Parameter – überprüfen Sie auch $_POST, $_REQUEST, $_FILES (falls Dates aus hochgeladenen Dateien stammen), Anfrage-N Bodies und Headers (z. B. If-Modified-Since). |
Konsistentes Muster über den gesamten Stack: überall dort, wo ein Datum gelesen wird, führen Sie die Validierung durch. |
Zusammenfassung: Die Anwendung sollte keine benutzerdefinierten Datumswerte verarbeiten, ohne zuerst sicherzustellen, dass sie genau dem erwarteten Format entsprechen und nur aus zulässigen Zeichen bestehen. Sobald das strenge Format durchgesetzt ist, wird der fehlerhafte String (
2026-01i5R1Ctbv'…) abgewiesen, bevor ein PHP-Datetime-Parser ausgelöst wird, und der SQL-Injection-Teil erreicht niemals den DB-Zugriff.
3️⃣ Betroffene TYPO3 Extension (am wahrscheinlichsten)¶
Die Fehlerstapel Spur führt durch den TYPO3-Kernel (index.php), gibt aber keinen Erweiterungsspezifischen Klassennamen an.
Da der Parser ein einfaches Datum (ohne Uhrzeit) erwartet, sind die Erweiterungen, die eine datumsbasierte Abfrage auf Benutzereingabe durchführen, die typischen Verdächtigen:
| Erweiterung | Typische Verwendung des Datumsparameters | Grund, warum es passen könnte |
|---|---|---|
news (TYPO3 CMS News) |
tx_news_pi1[date] – Filterung von Artikeln nach einem Datumsbereich |
Nachrichten-Plugin akzeptiert oft ein date-Parameter für die Liste. |
tt_address |
tx_ttaddress_pi1[date_of_birth] oder birthdate-Filter |
Verwendet Datums-Felder für Suchfunktionen. |
cal (Kalender) |
calendar[date] – wählt einen Tag für die Detailansicht aus |
Kalender-Erweiterungen parsen häufig Y-m-d-Strings. |
felogin |
tx_felogin_pi1[date] (Wiederherstellungs- / Bestätigungsdatumsfelder) |
Wird in Formular-Feldern für Passwort-Zwecke verwendet, die oft angreifbar sind. |
scheduler (Aufgabenplaner) |
task[date] – Filterung geplanter Aufgaben |
Backend-Modul mit Datums-Filtern. |
form (TYPO3 Form) |
Datums-Feld in Formular-Antworten, das direkt mit DateTime::createFromFormat geparst wird |
Wird oft auf dem Frontend gesendet. |
Warum diese?
Alle diese Erweiterungen stellen einen Parameter bereit, der als Datum interpretiert wird (oft date, from, to, day usw.) und durchlaufen keine strenge Validierung an der Grenze – sie übergeben den Rohwert an einen SQL-WHERE-Klausel oder eine DateTime-Instanz.
Daher ist die Injektion des Angreifers dort zu sehen.
Zusammenfassung: Die wahrscheinlichste Erweiterung ist
news(oder eine andere Erweiterung mit einem öffentlichen Datums-Filter), aber die gleiche Schwachstelle kann in jeder der oben genannten Erweiterungen existieren, die Datums-Eingaben akzeptieren.
4️⃣ Confidence-Level¶
| Faktor | Bewertung | Begründung |
|---|---|---|
| Stack-Trace-Abdeckung | 70 % | Zeigt den Kernel, aber nicht den Erweiterungs-Code. |
| Fehlermeldung | 85 % | DateMalformedStringException ist eindeutig eine Datums-Parsing-Schwäche. |
| Anwesenheit eines SQL-Injection-Musters | 80 % | Bestätigt, dass ein Angreifer versucht, schädliche Daten einzufügen. |
| Typische TYPO3-Erweiterungs-pattern | 65 % | Viele Erweiterungen verarbeiten date-Parameter ohne Validierung. |
| Insgesamt | 73 % | Starke Hinweise, aber der genaue Erweiterungskontext ist nicht in den Protokollen sichtbar. |
5️⃣ Sofortige Maßnahmen, die Sie jetzt ergreifen sollten¶
- Aktivieren Sie eine 500-Fehlerprotokollierung (falls noch nicht geschehen), damit zukünftige Angriffe den ursprünglichen rohen Anfrage-Parameter erfassen.
-
Fügen Sie eine Eingabeprüfung für alle Extension-Plugins hinzu, die Datums-Query-String-Parameter akzeptieren (erste Untersuchung:
news,tt_address,cal,felogin). - Veröffentlichen Sie ein Sicherheitsupdate für die betroffene(n) Erweiterung(s), das die strenge Datumsvalidierung implementiert (siehe Fix-Schritte oben).
-
Fügen Sie einen Content-Security-Policy-Header hinzu und erwägen Sie, SQL-Injection-Schutz (z. B.
typo3cms/coreverwendet bereits Prepared Statements) zu verstärken, um eine Defense-in-Depth-Strategie zu gewährleisten. - Überprüfen Sie alle vorhandenen Log-Einträge auf ähnliche malformed Date-Strings – der Angreifer könnte versucht haben, Daten zu exfiltrieren.
Zusammenfassend: Der Fehler tritt auf, weil TYPO3 (oder eine Erweiterung) einen ungesicherten, von einem Angreifer kontrollierten Wert an einen Datums-Parser übermittelt. Durch die Durchsetzung einer strengen Datumsformatvalidierung an der Grenze, die Verwendung von TYPO3s eigenen Datums-Routinen und die Ablehnung alles andere können Sie den Datums-Parsing-Absturz stoppen und den zugrunde liegenden SQL-Injection-Versuch blockieren. Die wahrscheinlichsten Erweiterungen, die betroffen sind, sind news, tt_address, cal, felogin, scheduler oder form. (Konfidenz ≈ 73 %).
Nichts anzuzeigen