www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/99916456-395d-43d2-8e37-321a174cb118/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026--1 OR 5*5=26 -- -01) at position 4 (-): Unexpected character

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers:

1. Ursache identifizieren¶

Der Fehler stammt aus einem SQL-Injection-Versuch, der sich als Datum tarnt. Der String "2026--1 OR 5*5=26 -- -01" ist keine gültige Datumsangabe, sondern eine typische SQL-Injection-Payload:

• 2026--1: Versuch, ein Datum zu manipulieren (Doppelminus als SQL-Kommentar).
• OR 5*5=26: Logischer SQL-Injection-Ansatz (wird ignoriert, da 5*5=25 ≠ 26, aber die Syntax ist gültig).
• -- -01: SQL-Kommentar, um den restlichen Query auszuschließen.

Die Ausnahme DateMalformedStringException wird geworfen, weil TYPO3 versucht, diesen String als Datum zu parsen (z. B. über DateTime::createFromFormat oder similar).

2. Fix beschreiben (konkret)¶

• Input-Validierung: User-Input muss strikt auf Datumsformat geprüft werden (z. B. mit DateTime::createFromFormat und Fehlerprüfung).
• Prepared Statements: Datenbankabfragen müssen immer mit Prepared Statements (z. B. $query->execute(['param' => $value])) durchgeführt werden, um SQL-Injection zu verhindern.
• Escaping: Falls keine Prepared Statements verwendet werden, müssen Werte mit $connection->quote($value) escaped werden.
• Fehlerbehandlung: Ungültige Datumsangaben sollten sofort abgefangen und nicht weiterverarbeitet werden.

3. Betroffene TYPO3 Extension¶

Der Fehler ist nicht extension-spezifisch, sondern betrifft die TYPO3 Core-Komponenten (z. B. Http\Application oder MiddlewareDispatcher). Die Schwachstelle liegt in der Art und Weise, wie User-Input in Datenbankabfragen oder Datumsparsern verwendet wird. Typische betroffene Erweiterungen:

• Kalender/Event-Extensions (z. B. cal, tx_calendar).
• News-Extensions (z. B. news, tx_news), die Datumsfilter aus der URL nutzen.
• Jede Extension, die User-Input direkt in DB-Queries oder Datumsfunktionen einsetzt.

4. Confidence (0-100%)¶

95%
Der Error ist eindeutig auf SQL-Injection zurückzuführen, und die Stacktrace zeigt, dass der Fehler in Core-Komponenten auftritt. Die fehlende Input-Validierung ist die primäre Ursache.

Empfehlung:
Überprüfen Sie alle Stellen, WHERE User-Input in SQL-Queries oder Datumsfunktionen eingesetzt wird. Nutzen Sie immer Parameters statt direkter String-Interpolation.