Projekt

Allgemein

Profil

Aktionen

Bug #343

offen

[Bugsink] DateMalformedStringException: Failed to parse time string (20266ytxxyeQ') OR 957=(SELECT 957 FROM PG_SLEEP(15))---01-01) at position 4 (6): Unexpecte…

Von Bug Sink vor 27 Tagen hinzugefügt.

Status:
Neu
Priorität:
wichtig
Zugewiesen an:
-
Beginn:
25.09.2026
Abgabedatum:
% erledigt:

0%

Geschätzter Aufwand:

Beschreibung

Bugsink: https://bugsink.cytrus.de/issues/issue/ae85810f-6533-4d22-8003-2d8240f222c0/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (20266ytxxyeQ') OR 957=(SELECT 957 FROM PG_SLEEP(15))---01-01) at position 4 (6): Unexpecte…


Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren

Root Cause: SQL-Injection-Angriff über den HTTP Host-Header, der in einen DateTime-Parser eingespeist wird.

Der fehlerhafte String:

20266ytxxyeQ') OR 957=(SELECT 957 FROM PG_SLEEP(15))---01-01)

ist ein klassischer PostgreSQL Time-Based Blind SQL-Injection-Payload. Die Struktur offenbart:

  • 20266 → wahrscheinlich als Jahr/Tag manipuliert
  • ytxxyeQ') → SQL-Closure (') beendet einen String-Literal)
  • OR 957=(SELECT 957 FROM PG_SLEEP(15)) → PostgreSQL Time-Based SQL Injection (verursacht eine 15-Sekunden-Verzögerung)
  • ---01-01) → versucht, das Datumsformat zu fälschen

Der DateMalformedStringException wird ausgelöst, weil PHP versucht, diesen bösartigen String als Datum zu parsen (wahrscheinlich via new DateTime() oder DateTime::createFromFormat()), an Position 4 (y nach 2026) scheitert.

Der Eintrittspunkt ist die TYPO3 Core Middleware VerifyHostHeader::process – der manipulierte Host-Header wird verarbeitet und enthält den Payload.


2. Fix (konkret)

Sofortmaßnahme:

  1. Host-Header-Validierung erzwingen: Nur alphanumerische Zeichen, Punkt (.) und Bindestrich (-) im Host-Header erlauben. Alle anderen Zeichen sofort blockieren.
// In der VerifyHostHeader Middleware oder einem eigenen Middleware-Wrapper:
$host = $request->getHeaderLine('Host');
if (!preg_match('/^[a-zA-Z0-9.\-]+$/', $host)) {
    throw new \InvalidArgumentException('Invalid host header');
}
  1. DateTime-Parsing niemals auf User-Input anwenden: Den Host-Header oder daraus abgeleitete Werte niemals an new DateTime(), DateTime::createFromFormat() oder ähnliche Funktionen übergeben.

  2. SQL-Injection-Schutz: Falls der Host-Header-Wert in SQL-Abfragen verwendet wird → Prepared Statements verwenden, niemals String-Interpolation.

TYPO3-spezifisch:

  1. VerifyHostHeader Middleware prüfen: Sicherstellen, dass die TYPO3 Core Version aktuell ist (security patches).
  2. Eigene Middleware oder Extension überprüfen, die den Host-Header weiterverarbeitet und als Datum parst.
  3. Web Application Firewall (WAF) oder Rate-Limiting konfigurieren, um solche Payloads abzufangen.

3. Betroffene TYPO3 Extension

Der Fehler tritt in der TYPO3 Core Middleware VerifyHostHeader auf (/vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php:55). Allerdings deutet der DateMalformedStringException darauf hin, dass eine benutzerdefinierte oder Drittanbieter-Extension den Host-Header unsicher an einen DateTime-Parser übergibt.

Die betroffene Komponente ist nicht eindeutig einer einzelnen TYPO3 Extension zuzuordnen, da die Stack-Trace zeigt, dass der Fehler innerhalb der Core-Middleware-Kette auftritt. Es ist jedoch sehr wahrscheinlich, dass eine Custom-Extension (oder eine Sicherheits-/Firewall-Erweiterung wie typo3/cms-core in Kombination mit einer Extension) den manipulierten Host-Header verarbeitet.

Hinweis: Ohne vollständige Projektstruktur ist die spezifische Extension nicht exakt identifizierbar. Prüfen Sie:

  • Eigene Middlewares im Configuration/Middleware.php
  • Event Listener, die den Host-Header verarbeiten
  • Security Extensions (z.B. typo3_console, rsaauth, saltedpasswords)

4. Confidence

75%

Begründung:

  • ✅ Die SQL-Injection-Natur des Payloads (PG_SLEEP(15)) ist eindeutig erkennbar – sehr hohes Vertrauen
  • ✅ Der Fehler DateMalformedStringException bei DateTime-Parsing von User-Input ist logisch nachvollziehbar
  • ✅ Der Eintrittspunkt VerifyHostHeader::process ist klar identifiziert
  • ❌ Die exakte betroffene Extension kann ohne Projektstruktur nicht eindeutig bestimmt werden – daher die Reduktion auf 75%

Empfehlung: Prüfen Sie sofort den HTTP-Request-Log, welcher Host-Header-Wert gesendet wurde, und suchen Sie im Code nach DateTime + getHeaderLine('Host') oder ähnlichen Mustern.

Nichts anzuzeigen

Aktionen

Auch abrufbar als: Atom PDF