www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/0ba30ae8-9559-4e15-b381-fed9a410fbba/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

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

Automatisch erstellt durch n8n

KI-Analyse:

TYPO3/PHP Fehleranalyse¶

1. Ursache identifizieren¶

Der Fehler DateMalformedStringException mit dem String -1 OR 5*5=25 -- -01-01 ist kein legitimer Datumswert, sondern ein SQL-Injection-Payload, der versehentlich (oder gezielt) in eine Datumsparsing-Funktion gelangt ist.

Zerlegung des Payload:

• -1 OR 5*5=25 → Klassisches SQL-Injection-Muster (WHERE id = -1 OR 5*5=25 — immer true)
• -- -01-01 → SQL-Comment (--) kombiniert mit einem Datumsfragment

Wahrscheinlicher Ablauf:

1. Ein Benutzerparameter (GET/POST/URL-Parameter) enthält den Injection-String
2. Ein TYPO3-Extension-Controller oder Repository erwartet einen Datumswert
3. Der ungefilterte Parameter wird direkt an eine PHP-Datumsfunktion übergeben (z.B. DateTime::__construct(), strtotime(), DateTime::createFromFormat())
4. PHP wirft die DateMalformedStringException, weil der String nicht als Datum parsbar ist

Konkreter Pfad: Der Fehler tritt während der Middleware-Verarbeitung auf (VerifyHostHeader → NormalizedParamsAttribute → ResponsePropagation), was darauf hindeutet, dass der bösartige Wert bereits im Request-Objekt vorliegt und beim Weiterleiten an die Anwendung verarbeitet wird.

2. Fix beschreiben (konkret)¶

Kurzfristig (Sicherheit):¶

// In der betroffenen Extension: Vor dem Datum-Parsing
// Input strikt validieren
$dateValue = $request->getQueryParams()['date'] ?? '';

// Nur zulässige Datumsformate erlauben (Whitelist!)
if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $dateValue)) {
    throw new \InvalidArgumentException('Invalid date format', 123456789);
}

// Oder mit strtotime mit Fehlerbehandlung:
$timestamp = strtotime($dateValue);
if ($timestamp === false) {
    throw new \InvalidArgumentException('Invalid date value', 123456790);
}

Mittelfristig (Architecture):¶

• In ext_localconf.php einen Middleware-Input-Filter einrichten, der bekannte SQL-Injection-Muster in GET/POST-Parametern blockiert
• Alle Datumsparameter über Typcastung absichern: (int) für Unix-Timestamps, Regex-Validierung für Datumsstrings
• In TypoScript Setup: parameterWH oder stdWrap-Filter verwenden, um Eingaben zu sanitären

TYPO3 Core-Seitig:¶

• Prüfen, ob in vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php Zeile 55 der Host-Header-Wert ungefiltert weitergeleitet wird
• Eventuell einen zusätzlichen Input-Sanitization-Step im NormalizedParamsAttribute einfügen

3. Betroffene TYPO3 Extension¶

Am wahrscheinlichsten betroffen: news (Extension-Key: news, Maintainer: Georg Ringer)

Begründung: Die news-Extension akzeptiert häufig Datumsparameter (z.B. tx_news_pi1[date], tx_news_pi1[overwriteDemand][start_date]) über GET/POST und verarbeitet diese direkt in Repository-Abfragen. Wenn ein solcher Parameter mit einem SQL-Injection-Payload gefüttert wird und keine ordnungsgemäße Eingabevalidierung stattfindet, landet der Payload im Datumsparser.

Alternativ möglich: calendarize, events2, oder eine benutzerdefinierte Extension mit Datumseingabefeldern.

4. Confidence¶

Bewertung: 78%

⚠️ Empfehlung¶

Dies könnte ein aktiver Sicherheitsangriff sein. Folgende Sofortmaßnahmen werden empfohlen:

1. Log-Dateien prüfen — Nach dem Ursprung des Requests suchen (IP-Quelle, refererer)
2. Alle Datumsparameter in allen Extensions auf Input-Validierung prüfen
3. TYPO3 Core und alle Extensions auf den neuesten Stand bringen
4. Einen Web Application Firewall (WAF)-Rule erwägen, die SQL-Injection-Patterns blockiert