Bug #335
offen[Bugsink] DateMalformedStringException: Failed to parse time string (2026-01-1) OR 942=(SELECT 942 FROM PG_SLEEP(15))---01) at position 9 ()): Unexpected chara…
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/c849d266-899a-4098-9a76-bdfe699c640e/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
DateMalformedStringException: Failed to parse time string (2026-01-1) OR 942=(SELECT 942 FROM PG_SLEEP(15))---01) at position 9 ()): Unexpected chara…
Automatisch erstellt durch n8n
KI-Analyse:
1. Ursache
Der Fehler entsteht durch eine unsanitisierte Benutzereingabe, die als Datum an eine PHP‑Funktion (z. B. strtotime/DateTime) übergeben wird. Der String enthält zwei Probleme:
-
Falsches Datum‑Format – „2026-01-1“ fehlt die Tages‑Ziffer (sollte „2026‑01‑01“ sein). Beim Parsen wird das unerwartete Zeichen „1)“ entdeckt →
DateMalformedStringException. - SQL‑Injection‑String – unmittelbar danach wird ein Teil des Eingabestrings zu „942=(SELECT 942 FROM PG_SLEEP(15))---01)“, also ein bewusst eingespielter SQL‑Injektionsversuch, der die Zeichenkette ungültig macht.
Damit wird intern ein fehlerhafter Zeitstring an die Datenbank weitergeleitet, was den Ausnahme‑Auslöser triggert.
2. Fix (konkret)
| Schritt | Maßnahme |
|---|---|
| Validierung | Prüfen Sie jede Eingabe, die als Datum verwendet wird, mit einer strikten Regex, z. B. if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $dateString)) { … }. |
| Parsen | Nutzen Sie DateTime::createFromFormat('Y-m-d', $dateString) und prüfen Sie das Ergebnis ($dateObj === false). |
| SQL‑Abfrage | Ersetzen Sie jede direkte String‑Konkatenation in SQL‑Statements durch Prepared Statements (PDO, MySQLi, TYPO3‑DB‑API). So wird die Eingabe automatisch escaped und kann nicht zu einer Injektion führen. |
| Fehlerbehandlung | Im Fehlerfall eine klare Fehlermeldung zurückgeben und die verarbeitende Komponente (Controller/Plugin) abbrechen, bevor die Datenbank erreicht wird. |
| Logging | Loggen Sie solche Invalid‑Date‑Strings mit Kontext (Request‑Parameter, User‑ID) für spätere Analyse, aber geben Sie keine rohen Eingaben in die Log‑Ausgabe. |
3. Betroffene TYPO3‑Extension
Der Stack‑Trace weist auf das TYPO3‑Core hin, aber die fehlerhafte Eingabe stammt aus einer Extension, die Datumseingaben aus Request‑Parametern auswertet. Häufig betroffen sind Erweiterungen wie news, form, siteconfig oder eigene Custom‑Extensions, die z. B. Datum‑Filter für Listen/Suche verwenden.
Konkret: Extension “news” (oder jede Extension, die Datum‑Parameter ohne Validierung verarbeitet).
4. Confidence
85 % – Die Analyse basiert auf den gegebenen Stack‑Trace‑Informationen und den typischen Schwachstellen (unsanitisierte Datumseingabe + SQL‑Injection) in TYPO3‑Extensions. Weitere Details würden eine genauere Inspektion des jeweiligen Extensions‑Codes erfordern.
Nichts anzuzeigen