www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/66b2a67a-363f-4d25-8894-bbc5f8736a3b/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

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

Automatisch erstellt durch n8n

KI-Analyse:

1️⃣ ROOT CAUSE

Die Exception wird geworfen, weil ein roher Wert aus der Anfrage (normalerweise ein Abfragezeichenfolgenparameter wie date, start, end, …) direkt an DateUtility::parseDateTime() (oder den intern verwendeten DateTime::createFromFormat) übergeben wird, ohne auf einen gültigen Datumsstring überprüft zu werden.

Der fehlerhafte String, den TYPO3 zu parsen versucht, lautet:

-1') OR 5*5=26 -- -01-01)

Dies ist keine gültige Datumsangabe – es sieht eher nach einer SQL-Injection-Ausregung aus. Da die Parser-Routine keinen Wert erkennen kann, der dem erwarteten ISO-8601/Datetime-Format (Y-m-d[, H:i:s]) entspricht, wird die DateMalformedStringException geworfen, und der gesamte Request löst eine 500-Fehlerpage aus.

Der Stacktrace zeigt, dass der Fehler im Core-Middleware auftritt, die für die „Normalisierung von Anforderungsparametern“ verantwortlich ist:

TYPO3\CMS\Core\Middleware\NormalizedParamsAttribute::process (Line 44)
   → DateUtility::parseDateTime()

Daher liegt die Ursache in der fehlenden Eingaberückisierung für alle Parameter, die später als Datum interpretiert werden können.

2️⃣ PRÄZISER FIX

Der Fix besteht darin, die Normalisierung anzuhalten, bevor ein nicht sicher validierter Datumsstring geparst wird. Es gibt zwei ergänzende Maßnahmen, die Sie ergreifen können:

Code-Snippet – Beispiel für NormalizedParamsAttribute (TYPO3 v11/v12)

<?php
namespace TYPO3\CMS\Core\Middleware;

use TYPO3\CMS\Core\Http\NormalizedParams;
use TYPO3\CMS\Core\Utility\DateUtility;
use TYPO3\CMS\Core\Exception\DateMalformedStringException;

final class NormalizedParamsAttribute implements MiddlewareInterface
{
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        $attributes = $request->getAttributes();
        $query      = $request->getQueryParams();

        // -----------------------------------------------------------------
        // Beispiel: Der Parameter name='date' (oder jedes andere, das von einer Extension genutzt wird)
        // wird als Datum geparst. Dies spiegelt die typische Verwendung in
        // Erweiterungen wie tt_address, news, fal usw. wider.
        // -----------------------------------------------------------------
        if (isset($query['date'])) {
            $raw = (string)$query['date'];

            // 1️⃣ Whitelist-Konsistenzprüfung (ISO-8601 ohne Zeitzone)
            if (preg_match('/^\d{4}-\d{2}-\d{2}( \d{2}:\d{2}:\d{2})?$/', $raw)) {
                try {
                    $date = DateUtility::parseDateTime($raw);
                    $attributes->setMatchedAttribute('date', $date);
                } catch (DateMalformedStringException $e) {
                    // Protokollieren Sie den fehlgeschlagenen Versuch – nützlich für die Sicherheitsüberwachung
                    // und halten Sie den Request-Prozess am Leben.
                    $attributes->setMatchedAttribute('date', null);
                    // Optional: Logger verwenden – z. B. $this->logger->warning('Datumsanalyse fehlgeschlagen', ['value' => $raw]);
                }
            } else {
                // Kein Datumsformat – beenden Sie die Datumsanalyse sicher.
                $attributes->setMatchedAttribute('date', null);
            }

            // Entfernen Sie den rohen Abfragewert aus den normalisierten Parametern,
            // damit spätere Komponenten nicht erneut versuchen, ihn als rohen String zu interpretieren.
            unset($query['date']);
            $request = $request->withQueryParams($query);
        }

        // -----------------------------------------------------------------
        // Fahren Sie mit der Middleware-Pipeline fort …
        // -----------------------------------------------------------------
        return $handler->handle($request);
    }
}

Wichtige Punkte des Snapshots:

• Regex stellt sicher, dass nur strings akzeptiert werden, die tatsächlich wie ein Datum aussehen.
• Das Try/Catch schützt vor Edge-Cases (z. B. gültiger Regex, aber ungültiger Monat wie 2022-13-01).
• Das Protokollieren des fehlgeschlagenen Versuchs gibt Ihnen eine Audit-Spur für zukünftige Angriffsversuche.
• Durch das unset von date aus den normalisierten Abfrageparametern wird verhindert, dass andere Middleware oder Extensions denselben fehlerhaften Wert erneut verarbeiten.

Wenn Sie nicht im Core-Modul, sondern in einer Extension arbeiten (z. B. tt_address verwendet startDate/endDate), platzieren Sie dieselbe Validierung/Catch-Logik in der Extension-Konfigurationsdatei oder in einem Extension-Splugin, das DateUtility::parseDateTime aufruft.

3️⃣ BETROFFENE TYPO3 EXTENSION

Die Ausnahme wird vom TYPO3 Core ausgelöst, genauer gesagt von TYPO3\CMS\Core\Middleware\NormalizedParamsAttribute.
Die meisten Drittanbieter-Erweiterungen, die Datumsabfrageparameter akzeptieren, sind indirekt betroffen, weil sie sich auf die Kernnormalisierung verlassen. Die am häufigsten genannten sind:

Wenn Sie eine dieser Erweiterungen installiert haben und einen Angreifer die Kontrolle über einen Datumsfilter erlangen kann, erhalten Sie denselben Fehler. Die sicherste Lösung besteht darin, den Core-Fix anzuwenden (oben) und dann diese Erweiterungen zu aktualisieren (oder einen Patch anzuwenden), um die neuen Validierungsschritte zu respektieren.

4️⃣ ZUVERLÄSSIGKEITSBEWERTUNG

TL;DR

• Die Exception wird durch einen ungeprüften Datumsabfrageparameter verursacht, der als Datumsstring geparst wird.
• Fügen Sie Regex-Whitelist-Validierung + Try/Catch-Protokollierung in der Normalisierung Middleware (oder wo auch immer DateUtility::parseDateTime aufgerufen wird) hinzu.
• Die Änderung betrifft den TYPO3 Core (speziell NormalizedParamsAttribute) und alle Erweiterungen, die auf dieses Feature zurückgreifen (tt_address, news, fal, realurl, form usw.).
• Vertrauen Sie der Lösung mit ~90 % Vertrauen nach der Bereitstellung.