www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/4fc9e14f-65a4-440b-a80e-5124cc8dfbfd/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026M0zlLecx')) OR 836=(SELECT 836 FROM PG_SLEEP(15))---01-01) at position 5 (0): Unexpect…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache
Der Request‑Parameter, der als Datum ausgewertet wird, enthält den manipulierten String 2026M0zlLecx')) OR 836=(SELECT 836 FROM PG_SLEEP(15))---01-01. Beim Versuch, diesen String mit DateTime/strtotime zu parsen, wirft PHP die DateMalformedStringException. Gleichzeitig wird der enthaltene SQL‑Injection‑Payload (OR 836=...) in eine Datenbankabfrage eingebunden, was zu einem temporären „Sleep“-Attacke führt. Der Fehler entsteht also durch fehlende Validierung und sanitizing von Datumseingaben.

2. Fix

• Ein Eingabe‑Validierung: Stellen Sie sicher, dass nur ein Datum im erwarteten Format (z. B. Y-m-d oder ISO‑8601) übermittelt wird. Verwenden Sie eine strenge Whitelist‑Prüfung (z. B. Regex /^\d{4}-\d{2}-\d{2}$/) und verwerfen Sie alles, was nicht dem Format entspricht.
• Sanitizing: Entfernen bzw. escapeen Sie alle nicht‑numerischen Zeichen, bevor die DateTime‑Parsing‑Funktion aufgerufen wird.
• SQL‑Sicherheit: Nutzen Sie immer parametrisierte Abfragen (prepared statements) oder TYPO3‑Database‑API‑Methoden ($GLOBALS['TYPO3_DB']->exec() mit gebundenen Parametern), um eine SQL‑Injection zu verhindern.
• Logging/Monitoring: Implementieren Sie ein Logging für verdächtige Eingaben (z. B. nicht‑datumskonforme Strings) und setzen Sie Rate‑Limits, um automatisierte Angriffe zu erschweren.

3. Betroffene Extension
Der Fehler wird ausgelöst, sobald eine Extension/Modul die unsanitisierte Datum‑Variable übernimmt – typischerweise die News‑Extension (oder jede andere Extension, die Datum‑Parameter über GET/POST‑Parameter verarbeitet, z. B. search oder site). In diesem Kontext ist die News‑Extension die häufigste Ursache.

4. Confidence
92 %