www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/9832ebbb-ffa2-49ca-8084-a57d0cc208e2/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

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

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache
Ein vom Client übermittelter Parameter (z. B. GET‑ oder Post‑Wert) enthält den String

2026--1' OR 5*5=25 -- -01

und wird ohne vorherige Validierung direkt an den PHP‑DateTime‑Konstruktor (oder DateTimeImmutable::__format) übergeben. Der String entspricht keinem gültigen Datumsformat; nach dem ersten Bindestrich‑Paar (2026--) folgt ein Apostroph und ein SQL‑Injection‑Versuch, wodurch DateMalformedStringException: Failed to parse time string … at position 4 (-): Unexpected character ausgelöst wird.

2. Fix (konkret)
Bevor ein Datum‑Objekt erzeugt wird, muss der Eingabewert auf ein erwartetes Format geprüft werden. Beispielhafte Umsetzung:

use DateTimeImmutable;
use DateTimeZone;
use TYPO3\CMS\Core\Utility\GeneralUtility;

$raw = GeneralUtility::_GET('date') ?? '';   // oder POST‑Wert entsprechend

// Erwartetes Format: YYYY-MM-DD (oder ggf. YYYY-MM)
if (preg_match('/^\d{4}-\d{2}(-\d{2})?$/', $raw)) {
    $dateTime = DateTimeImmutable::createFromFormat(
        'Y-m-d',   // bzw. 'Y-m' wenn nur Jahr‑Monat erlaubt ist
        $raw,
        new DateTimeZone('UTC')
    );
    // Prüfen, dass kein Parsing‑Fehler vorliegt
    $errors = DateTimeImmutable::getLastErrors();
    if ($dateTime !== false && $errors['warning_count'] === 0 && $errors['error_count'] === 0) {
        // $dateTime kann weiter verwendet werden
    } else {
        // Ungültiges Datum → Standardwert oder Exception werfen
        throw new \InvalidArgumentException('Invalid date supplied', 1595678901);
    }
} else {
    // Format nicht zulässig → BadRequest oder Default
    throw new \BadRequestException('Malformed date parameter', 1595678902);
}

Kurz gesagt:

• Eingabe whitelist‑validieren (Regex oder DateTime::createFromFormat mit anschließendem Fehlercheck).
• Bei Fehlern entweder einen sinnvollen Defaultwert verwenden oder eine BadRequestException/InvalidArgumentException werfen – niemals den rohen String an new DateTime() übergeben.
• Optional kann man die Eingabe über TYPO3‑Eingabe‑Hilfen (GeneralUtility::sanitizeNumVal, Input->getInt etc.) filtern, bevor sie beim Datums‑Parsing benutzt wird.

3. Betroffene TYPO3‑Extension
Der Stacktrace zeigt, dass der Fehler in TYPO3\\CMS\\Core\\Middleware\\NormalizedParamsAttribute::process auftritt – dieses Middleware‑Komponente wird von jeder Extension benutzt, die Rohparameter an das Framework übergibt und versucht, sie zu typisierten Attributen (z. B. DateTimeImmutable) zu konvertieren.

Die häufigsten Erweiterungen, die ein reines Datums‑Feld über GET/POST übergeben und dabei auf dieses Middleware‑Verhalten angewiesen sind, sind:

• tx_news (Extension „news“) – Parameter wie tx_news_pi1[overwriteDemand][date] bzw. Monats/Jahr‑Filter.
• Eigene Erweiterungen oder sog. „Site‑Packages“, die ein Datums‑Eingabefeld (z. B. Geburtstag, Veranstaltungstermin) ohne vorherige Validierung auswerten.

Kurz: Jede Erweiterung, die ein Datums‑Parameter unmittelbar an das TYPO3‑Request‑Handling übergibt und dabei auf das automatische Typ‑Casting von NormalizedParamsAttribute vertraut, ist betroffen. In der Praxis tritt das am häufigsten bei der „news“-Extension bzw. bei selbstgeschriebenen Erweiterungen auf, die ein ähnliches Muster verwenden.

4. Confidence
95 % – Der Fehler liegt eindeutig im Parsen eines Zeitstrings innerhalb des TYPO3‑Kern‑Middlewares, und der auffällige String enthält ein klassisches SQL‑Injection‑Muster (--). Die beschriebenen Ursache‑ und Fix‑Schritte adressieren exakt diese Situation.