Bug #329
offen[Bugsink] DateMalformedStringException: Failed to parse time string (2026-01-1; waitfor delay '0:0:15' -- -01) at position 9 (;): Unexpected character
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/36224c86-0f74-4d4a-8fd3-d04095a778a2/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
DateMalformedStringException: Failed to parse time string (2026-01-1; waitfor delay '0:0:15' -- -01) at position 9 (;): Unexpected character
Automatisch erstellt durch n8n
KI-Analyse:
Ursache des Problems
DateMalformedStringException: Failed to parse time string (2026‑01‑1; waitfor delay '0:0:15' -- -01) at position 9 (;): Unexpected character
Die Anwendung versucht, einen String, der vom Benutzer bereitgestellt wurde, als Datum zu parsen. Der String enthält ein Semikolon und das bekannte „Wait‑for‑delay“-Payload, das in Timing-Angriffen verwendet wird. Da der Parser kein Semikolon innerhalb eines Datumsformats erwartet, löst er die Ausnahme aus.
Wie das Problem auftritt
- Eine Anforderung erreicht
index.php(Stacktrace:/public/index.php:21 → …). - Eine TYPO3-Extension, die einen Wert des Anforderungsparams (normalerweise
date,startdate,enddateusw.) ohne Validierung an die Datums Parser-Funktion weiterleitet. - Der Parser (
\DateTime::createFromFormat/\DateTimeImmutable::createFromFormatoder ein Wrapper wie\TYPO3\CMS\Core\Utility\DateUtility::parseDate) erhält den kontaminierten String. - Der String entspricht nicht dem erwarteten Format (
Y-m-d), da er nun zusätzliche Zeichen und einen SQL-Injection-ähnlichen Kommentar enthält, was zuDateMalformedStringExceptionführt.
Wichtige Frames (was der Stacktrace Ihnen sagt)
/public/index.php:21 /public/index.php:20 (Closure)
/vendor/typo3/cms-core/Classes/Http/AbstractApplication.php:110
/vendor/typo3/cms-core/Classes/Http/Application.php:44
/vendor/typo3/cms-core/Classes/Http/MiddlewareDispatcher.php:70,162
/vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php:55
/vendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php:44
/vendor/typo3/cms-core/Classes/Middleware/ResponsePropagation.php:34
Dies sind nur die generischen Core-Request-Handler – sie zeigen, dass der Fehler während der normalen Anfrageverarbeitung auftritt und nicht in benutzerdefiniertem Backend-Code.
Schweregrad / Auswirkungen
- Die Ausnahme führt zu einer 500-Fehlerseite, wodurch die Seite für die Anfrage nicht verfügbar ist.
- Die Datenverkehrsprotokolle können mit fehlerhaften Parsings gefüllt sein, wenn ein Angreifer wiederholt solche Eingaben sendet (DoS-ähnliches Verhalten).
- Das Vorhandensein eines „Waitfor-Delay“-Strings deutet auf einen Versuch hin, einen Timing-Angriff auszuführen. Die tatsächliche Datenbank ist in diesem Fall irrelevant, aber das Muster zeigt, dass die Eingabevalidierung fehlt.
Konkreter Fix
| Was | Warum | Wie (TYPO3-spezifisch) |
|---|---|---|
| Validieren Sie die Eingabe, bevor Sie sie an einen Datums Parser weiterleiten. | Stellen Sie sicher, dass der String dem erwarteten Datumsformat entspricht und keine unerwarteten Zeichen wie ;, ', -- usw. enthält. |
Implementieren Sie eine Whitelist-Validierung (z. B. Regex ^[0-9]{4}-[0-9]{2}-[0-9]{2}$). Wenn der Wert diese Validierung nicht besteht, verwerfen Sie ihn oder ersetzen Sie ihn durch einen sicheren Standardwert. |
| Verwenden Sie eine Typoscript-basierte Datumsformatkonfiguration für den Parser. | Das Standard-Datetime-Parser-Objekt von TYPO3 wirft bereits DateMalformedStringException aus; wir müssen die Ausnahme abfangen und ordnungsgemäß verarbeiten. |
Im Extension-Code fügen Sie einen try-catch-Block hinzu:try {<br> $dateTime = new \DateTimeImmutable($userInput);<br>} catch (\DateMalformedStringException $e) {<br> // Protokollieren, zurücksetzen auf NULL oder Use a default date<br> $dateTime = null;<br>}
|
Wird empfohlen, TYPO3s DateUtility::parseDate für Extension-Entwickler zu verwenden. |
Diese Utility-Wrapper behandelt bereits fehlerhafte Strings und kann ein Array mit Fehlerflag zurückgeben. |
\TYPO3\CMS\Core\Utility\DateUtility::parseDate($userInput) gibt ['year'=>..., 'month'=>..., 'day'=>...] zurück oder false. Überprüfen Sie das Ergebnis, bevor Sie es weitergeben. |
| Begrenzen Sie die Eingabegröße und Server-seitige Parameter. | Verhindert, dass große Payloads den Parser überlasten. | Stellen Sie sicher, dass das Frontend-Plugin/Field-Type maxsize / length-Einschränkungen festlegt und die Extension die Länge der String-Eingabe überprüft. |
| Implementieren Sie Sicherheitsheader / Input-Sanitization-Middleware. | Obwohl der Core bereits Host/Host-Header-Verifizierung durchgeführt hat, ist eine strengere Validierung von Anfrageparametern sinnvoll. | Fügen Sie bei Bedarf eine benutzerdefinierte Middleware hinzu, die schädliche Muster (z. B. waitfor delay, --) in GET/POST-Parametern blockiert. |
Typische betroffenen Erweiterungen
Die Funktionsweise ist in jeder Extension zu finden, die ein Datum aus GET/POST liest und es an einen Datums Parser weiterleitet. Die am häufigsten betroffenen Erweiterungen sind:
| Erweiterung | Typische Verwendung von Datumsfeldern | Grund, warum sie betroffen sein könnten |
|---|---|---|
TYPO3 News (news) |
startdate, enddate, archive
|
Das Plugin verwendet news.date, news.date_end als Filter für Kategorien/Archive. |
TYPO3 Event (event) |
event.starttime, event.stoptime
|
Frontend-Search-/Calendar-Plugin liest diese direkt aus GET-Parametern (s). |
| tt_news | tt_news.date |
Älteres News-Plugin, das immer noch von vielen Legacy-Installationen verwendet wird. |
Formular-basierte Erweiterungen (fem, contact) |
„Datum“-Felder in Formularen | Wenn das Formular das rohe POST-Datum an ein Datumsobjekt übergibt, kann es missbraucht werden. |
Basierend auf der Analyse der Stacktrace-Dateien und der Tatsache, dass der Fehler während der normalen Anfrage an index.php auftritt, ist die Erweiterung „news“ (oder ein beliebiger Kalender-/Filter-Plugin, das ein date-Parameter liest) die wahrscheinlichste Ursache. In den meisten Produktionsumgebungen zeigt das Muster der betroffenen Erweiterung jedoch „news“ oder „event“ an.
Konfidenz – 70 % (Der Stacktrace ist generisch; der genaue Extension-Name kann ohne eine Durchsicht des betroffenen Felds oder der Protokolle nicht bestätigt werden, aber das „waitfor delay“-Pattern passt zum bekannten Missbrauch eines Datumsfelds in TYPO3 News/Event-Filtern).
Zusammenfassung
Der Fehler wird durch ungeprüfte Benutzer-Eingabe verursacht, die als Datumsstring interpretiert wird. Der Fix besteht darin, die Eingabe vor dem Parsen zu validieren (oder eine sichere Parsing-Utility zu verwenden) und den Standard-Ausnahmefall zu verarbeiten. Die Erweiterung, die das rohe Datumsfeld liest (am häufigsten TYPO3 News oder Event), muss aktualisiert werden, um die neue Validierung/Abfangung zu implementieren. Sobald die Extension die Eingabe whitelists oder eine DateMalformedStringException ordnungsgemäß behandelt, sollte das „Waitfor-Delay“-Payload als ungültiges Datum abgelehnt werden, anstatt eine Ausnahme auszulösen, die zu einem 500-Fehler führt.
Nichts anzuzeigen