www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/c9234628-0d3c-4d12-a2d9-903de58bc195/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026L5f80Tn8'; waitfor delay '0:0:15' -- -01-01) at position 5 (5): Unexpected character

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifiziert
Der Fehler entsteht, weil TYPO3 versucht, einen vom Client übermittelten Zeit‑/Datumsstring zu parsen (z. B. über strtotime() oder DateTime::createFromFormat). Der übermittelte String ist jedoch stark manipuliert und enthält SQL‑Injection‑Payload (2026L5f80Tn8'; waitfor delay '0:0:15' -- -01-01). Beim Versuch, diesen String als Datum zu interpretieren, trifft die Parsing‑Funktion auf das Zeichen „L“ an Position 5 und wirft deshalb eine DateMalformedStringException.

2. Fix beschrieben (konkret)

• Einstiegssanierung: Alle übermittelten Datum‑/Zeit‑Parameter streng validieren, bevor sie an die PHP‑Dateifunktionen übergeben werden.

  // Beispiel für eine sichere Validierung
  $raw = $GLOBALS['TYPO3_CONF']['BE']['timeZone']; // oder das eigentliche Datum‑Param
  $date = filter_input(INPUT_GET, 'date', FILTER_SANITIZE_STRING);
  
  // Prüfen, ob der Wert dem erwarteten Format (z. B. Y-m-d) entspricht
  if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $date)) {
      // Ungültiges Format → Fehler abfangen oder 400 Bad Request zurückgeben
      throw new \InvalidArgumentException('Ungültiges Datum');
  }
  
  // Optional: in ein DateTime‑Objekt umwandeln und weiter prüfen
  $dt = DateTime::createFromFormat('Y-m-d', $date);
  if ($dt === false || $dt->format('Y-m-d') !== $date) {
      throw new \InvalidArgumentException('Datum ist nicht parsbar');
  }
  

• Generelle Maßnahmen
  1. Keine direkte Weitergabe von rohen Nutzer‑Input an Datum‑Parser; stattdessen ein Whitelist‑Schema verwenden.
  2. Prepared Statements für alle Datenbank‑Abfragen einsetzen, um SQL‑Injection‑Versuche zu verhindern (die hier offenbarte Payload ist ein klassisches SQL‑i‑Muster).
  3. Input‑Sanitizer von TYPO3 (z. B. GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Utility\\GeneralUtility')->stripTags(), intval(), floatval()) einsetzen, bevor das Datum in kritische Pfade gelangt.
  4. Middleware‑Überprüfung: Das VerifyHostHeader‑Middleware (oder andere Sicherheits‑Middlewares) kann zusätzliche Checks auf ungewöhnliche Payload‑Muster durchführen.

3. Betroffene TYPO3 Extension
Da der Stack‑Trace ausschließlich TYPO3‑Core‑Klassen (Core‑Bootstrap, Middleware) zeigt, ist die fehlerauslösende Extension diejenige, die den fehlerhaften Datum‑Parameter (z. B. tx_myextension[date], controller_action[date], settings[date] usw.) an das Core‑Framework übergibt. Ohne konkrete Extension‑Namen lässt sich das nicht exakt benennen – es handelt sich um jede Extension, die benutzer‑gesteuerte Datumswerte an AbstractApplication::run() übergibt (z. B. siteconfig, news, survey, surveyor, etc.).

4. Confidence (0‑100 %)
92 % – Der Stack‑Trace und die Fehlermeldung deuten eindeutig auf eine fehlerhafte Datums‑Parsing‑Einleitung durch einen manipulierten Nutzer‑Input hin. Die vorgeschlagenen Sanierungs‑ und Validierungs‑Schritte sind die üblichen Mittel, um genau dieses Szenario in TYPO3 zu beheben.