www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/1bb22289-9aaf-4620-a43d-b4b9eb9b74d2/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:

1. Ursache identifizieren (Root Cause)¶

Die Fehlermeldung DateMalformedStringException: Failed to parse time string (2026--\' OR 5*5=26 -- -01) deutet auf einen SQL-Injection-Versuch hin, der in ein Datumsfeld injiziert wurde.

Besonders auffällig ist die Zeichenkette:

2026--' OR 5*5=26 -- -01

Diese entspricht keinem gültigen Datum. Sie enthält:

• Ein JavaScript-Datum 2026-...
• SQL-Kommentarzeichen --
• Eine Kalkulationsanweisung 5*5=26 (falsch, aber scheinbar absorbiert)
• Weitere SQL-Kommentare und ein falsches Datum -01

Mögliche Ursache:¶

Dieser Fehler taucht typischerweise auf, wenn:

• Eine Extension oder ein Skript benutzerdefinierte Eingaben in ein Datumsfeld schreibt, ohne diese zu validieren oder zu escapen.
• Der Timestamp-Wert (z. B. aus einer URL-Parameter wie ?date=2026--' OR 5*5=26 -- -01) nicht ordnungsgemäß aufbereitet wird.
• Die ** $_GET oder $_POST-Daten** direkt in eine SQL-Abfrage oder in ein DateTime-Objekt fließen, ohne Sicherheits- oder Validierungschecks.

Im Stacktrace ist zu sehen, dass der Fehler bereits im frühen Middleware-Schritt (VerifyHostHeader, NormalizedParamsAttribute, ResponsePropagation) auftritt – was darauf hindeutet, dass die eigentliche Anfrageanalyse bereits fehlerhaft ist. Allerdings scheint die Exception in einer tieferen Schicht aufzutreten, wo ein Datum geparst wird, z. B. in einer Database-Abfrage, die intern ein DateTime-Objekt erwartet.

2. Fix beschreiben (konkret)¶

Schritt-für-Schritt-Fix:¶

1. Eingabedaten validieren und sanitieren

   • Vor allem bei Datumsfeldern sollte geprüft werden, ob der eingehende Wert ein gültiges Datum oder Timestamp ist.
   • Verwendung von DateTime::createFromFormat() oder TYPO3-eigenen Hilfsmethoden wie GeneralUtility::makeInstance(DateTime::class, $value).

   try {
       $date = GeneralUtility::makeInstance(DateTime::class, $inputDate);
   } catch (\Exception $e) {
       // Fallback oder Fehlerbehandlung
       $date = GeneralUtility::makeInstance(DateTime::class, 'now');
   }
   

2. Use strict input filtering in GET/POST parameters

   • Beispiel:

     $dateString = filter_input(INPUT_GET, 'date', FILTER_SANITIZE_STRING);
     if (!checkdate(...)) { ... } // oder Regex-Prüfung
     

3. SQL-Injection verhindern

   • Alle Datenbankwerte sollten über PDO-Parameter binding oder TYPO3-Abfragen mit QueryParser gespeichert werden:

     $queryBuilder->select(...)
         ->where($queryBuilder->expr()->lte('date_field', ':date'))
         ->setParameter('date', $safeDate);
     

4. Host-Header und Request-Parameter validieren

   • Im Middleware-Bereich (wie in VerifyHostHeader) sollten unerwartete oder manipulierte Parameter abgefangen werden.

5. Extensions prüfen, die Datumswerte verwenden

   • Insbesondere Extensions, die Kalender-, Events-, News- oder Archivfunktionen anbieten.

3. Betroffene TYPO3 Extension nennen¶

Obwohl der Stacktrace keine direkte Extension nennt, deutet die Fehlermeldung typischerweise auf folgende Kategorien hin:

Mögliche Extensions:¶

• News System (news) – wenn News-Listen nach Datum gefiltert werden
• Calendar Management (cal), Eventsmanager
• Indexed Search oder Search Forms mit Datumsoptionen
• Eigenentwickelte Extensions, die:
  • URL-Parameter wie ?date=... akzeptieren
  • Diese direkt in Datenbankabfragen oder DateTime-Objekte schreiben

💡 Keine konkrete Extension nennen, da keine Extension im Stacktrace erwähnt wird. Der Fehler taucht im Core-Middleware-Bereich auf, wahrscheinlich ausgelöst durch eine externe Extension.

4. Confidence (0–100%)¶

✅ Zusammenfassung¶

• Problem: SQL-Injection-Versuch in einem Datumsfeld, der zu einem DateMalformedStringException führt.
• Ursache: Fehlende Validierung/Sanitierung von Benutzereingaben (GET-Parameter).
• Lösung: Eingaben validieren, DateTime-Objekte sicher erstellen, PDO-Binding nutzen.
• Betroffen: Wahrscheinlich eine Extension, die Datumseingaben verarbeitet (keine konkrete im Trace).
• Confidence: ~78% – deutlich analysierbar, aber keine 100%ige Sicherheit ohne Code-Inspect.