www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/3b091610-820f-44c6-9320-2e566228977b/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¶

Der Fehler DateMalformedStringException wird durch einen SQL-Injections-Versuch ausgelöst, der als Zeitstring interpretiert wird:

• Der bösartige String (2026--1') OR 5*5=26 -- -01) ist klassisches SQL-Injection-Syntax-Muster (' OR 1=1 --)
• Dieser String wird über einen HTTP-Header (wahrscheinlich Host oder X-Forwarded-Host) oder einen Request-Parameter übergeben
• Irgendeine Stelle im TYPO3-Request-Lifecycle (vermutlich im Bereich der NormalizedParamsAttribute-Middleware oder einer daran angeschlossenen Extension) übergibt diesen Wert an eine DateTime-Konstruktion oder strtotime()-Funktion, ohne ihn zuvor zu validieren
• PHP versucht den String als Datum zu parsen und scheitert an Position 4 (-)

Konkrete Ursache: Unvalidierte Benutzereingabe (Header/Parameter) wird direkt an eine Datumsparsing-Funktion übergeben. Der SQL-Injection-String wird zuerst vom PHP-Dateparser abgefangen, bevor er überhaupt die Datenbank erreicht.

2. Fix beschreiben (konkret)¶

1. Eingabevalidierung: Alle HTTP-Header-Werte und Request-Parameter, die als Datum verwendet werden, müssen vor der Übergabe an DateTime::createFromFormat(), strtotime() oder ähnliche Funktionen validiert werden. Nutze strenge Regex-Validierung (z.B. /^\d{4}-\d{2}-\d{2}$/ für Datumsformate).

2. TYPO3 Core-Seite (Middleware): In vendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php und VerifyHostHeader.php sicherstellen, dass Header-Werte vor der Weiterverarbeitung gefiltert werden. Der Host-Header sollte parse_url()-Validierung unterzogen werden.

3. Schutzmaßnahme: Folgenden Filter in die composer.json der betroffenen Extension oder in die AdditionalConfiguration.php einbauen:

// In der Initialisierung oder Middleware:
$rawValue = $request->getHeaderLine('X-Custom-Date'); // oder Parameter
if (!preg_match('/^\d{4}-\d{2}-\d{2}(?: \d{2}:\d{2}:\d{2})?$/', $rawValue)) {
    throw new \InvalidArgumentException('Invalid date format');
}

4. SQL-Injection-Schutz sicherstellen: Stellen Sie sicher, dass quoteStr() oder Prepared Statements in allen Datenbankabfragen verwendet werden – unabhängig davon, ob der Wert ein Datum zu sein scheint.

3. Betroffene TYPO3 Extension¶

Basierend auf der Stack-Trace-Analyse betrifft dies primär die TYPO3 Core-Middleware:

• TYPO3\CMS\Core\Middleware\VerifyHostHeader (Position 55)
• TYPO3\CMS\Core\Middleware\NormalizedParamsAttribute (Position 44)

Die eigentliche vulnerable Stelle liegt wahrscheinlich in einer benutzerdefinierten Extension (oder einer Drittanbieter-Extension), die eine benutzerdefinierte Middleware oder einen Hook implementiert, der Request-Header/Parameter als Datum verarbeitet. Es ist möglich, dass dies die Extension sr_feuser_register, felogin oder eine benutzerdefinierte List-Extension ist, die tx_[extension]_[table].-Parameter mit Datumsangaben verarbeitet.

4. Confidence¶

85%

Begründung: Die Diagnose der SQL-Injection ist eindeutig und das Fehlermuster ist klar (Datumsparsing schlägt fehl). Die exakte betroffene Extension kann ohne vollständigen Codezugriff der Drittanbieter-Extensions nicht mit 100% Sicherheit bestimmt werden, aber die Angriffsmethode und der Mechanismus sind klar identifiziert.