Bug #341
offen[Bugsink] DateMalformedStringException: Failed to parse time string ((select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)fr…
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/db3a2389-c2f0-49d7-a08a-880b086788a2/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
DateMalformedStringException: Failed to parse time string ((select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)fr…
Automatisch erstellt durch n8n
KI-Analyse:
1. Ursache identifiziert
Der Fehler entsteht, weil ein request‑Parameter (z. B. ein Datum) mit einer SQL‑Injektions‑Payload‑Zeichenkette übergeben wird:
((select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'\"+(select(0)from(select(sleep(15)))v)+\"*/-01-01)
Dieser String wird von TYPO3s DateTime‑Parsing (z. B. strtotime/DateTime::createFromFormat) versucht zu interpretieren. Durch die eingebetteten Sub‑Queries (sleep(15)) wird die Eingabe zu einer ungültigen Zeitangabe, woraufhin das DateTime‑Objekt einen Fehler wirft. Der anschließende Hinweis „The timezone could not be found in the database“ ist ein Nebeneffekt – das Parsing schlägt fehl, bevor die Zeitzone ermittelt werden kann.
2. Fix beschrieben (konkret)
| Schritt | Maßnahme |
|---|---|
| Input‑Validierung | Alle Datum‑/Zeit‑Parameter streng validieren (z. B. mit Regex ^\d{4}-\d{2}-\d{2}$ oder DateTime::createFromFormat('Y-m-d')). |
| Whitelist‑Ansatz | Nur erwartete Zeichen (Ziffern, Bindestrich, Doppelpunkt) zulassen; alle anderen Zeichen (z. B. ( ) * ' " /* */) sofort verwurfen. |
| Escaping / Parameterisierung | Wenn das Datum über ein DB‑Statement übergeben wird, nutze prepared statements / parametrisierte Queries, um SQL‑Injection zu verhindern. |
| Zeitzone‑Konfiguration | Stelle sicher, dass die Zeitzone in config.yaml/.env korrekt definiert ist (z. B. timezone: Europe/Berlin). TYPO3 sollte damit keine „Zeitzone nicht gefunden“-Meldungen mehr werfen. |
| Fallback‑Handling | Im Fehlerfall eine sinnvolle Fehlermeldung zurückgeben und das Request‑Objekt nicht weiterverarbeiten, um die Ausführung zu stoppen. |
| Security‑Review | Prüfe alle Stellen, an denen benutzerdefinierte Daten (GET/POST/QUERY) in das Core‑DateTime‑Parsing gelangen (z. B. FormEngine, RequestHandler, eigene Extensions). |
3. Betroffene TYPO3 Extension
Der Kern von TYPO3 CMS ist betroffen (DateTime‑Parsing im Core). Jede Extension, die unveränderten Request‑Parameter (z. B. aus GET‑Variablen, Formularfeldern oder API‑Calls) als Datum übergibt, kann den Angriff auslösen. Typische Beispiele:
- eigene
Controller‑Methoden, die z. B.startDate/endDateaus$_GETauslesen, - Plugins/Formular‑Definitionen, die Datumseingaben ohne Validierung übergeben,
- Extensions, die das
date‑Parameter‑Handling in eigenenDataProviders oderRepository‑Methoden übernehmen.
4. Confidence (0‑100 %)
95 % – Die Analyse basiert auf dem klaren Stack‑Trace (DateMalformedStringException) und dem bekannten Muster einer SQL‑Injection‑Payload, die in einen Datei‑Parser gelangt. Das Szenario ist in TYPO3‑Umgebungen häufig, sodass die Ursache mit hoher Wahrscheinlichkeit so beschrieben ist.
Nichts anzuzeigen