www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/e5c1e4e9-9399-4b39-9e40-cf864d12d699/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026-01-1)) OR 977=(SELECT 977 FROM PG_SLEEP(15))---01) at position 9 ()): Unexpected char…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Der Fehler deutet auf einen SQL-Injection-Versuch hin, der in einem TYPO3-Kernverfahren sichtbar wird.

Genauer: In /public/index.php:21 wird ein nicht validiertes Eingabeparameter (vermutlich $_GET oder $_POST) an eine Methode übergeben, die einen Zeitstempel oder Datumsstring verarbeitet. Das Script versucht, den String 2026-01-1)) OR 977=(SELECT 977 FROM PG_SLEEP(15))---01) als Datum zu parsen, was fehlschlägt.

Die Angreifer-Injection OR 977=(SELECT 977 FROM PG_SLEEP(15)) ist ein typischer PostgreSQL-basierter Time-Based Blind SQL-Injection-Angriff, um die Anwendung zu verlangsamen oder Daten zu extrahieren.

Die Ursache liegt in fehlender Eingabevalidierung irgendwo im Entry-Point oder MiddlewareStack, bevor TYPO3's NormalizedParamsAttribute oder VerifyHostHeader-Middleware den Request verarbeitet.

2. Fix beschreiben (konkret)¶

Sofortmaßnahme:¶

1. Prüfe /public/index.php Zeile 17–21:

   $response = $app->handle($request);
   

   Stelle sicher, dass $request nicht bereits manipuliert wurde – indem du prüfst, ob irgendeine Middleware oder ein früher Controller/Domain-Code den Request direkt verändert hat.

2. Setze strict Type Hints und Validierung ein, falls dort Parametereingaben wie _GET['tx_shopping_cart_pi1']['action'] etc. verwendet werden:

   $action = GeneralUtility::_GET('tx_shopping_cart_pi1.action') ?? '';
   if (!in_array($action, ['detail', 'list', 'checkout'])) {
       throw new \InvalidArgumentException('Invalid action');
   }
   

3. Erweiterte Middleware hinzufügen, z. B. im Configuration/Services.yaml:

   services:
     MyCompany\MyExt\Middleware\InputValidationMiddleware:
       tags:
         - { name: 'middleware', priority: 100 }
   

   Und dann implementiere die Validierung logisch gegen SQL-Injection-Muster:

   class InputValidationMiddleware implements MiddlewareInterface {
       public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface {
           foreach ($request->getQueryParams() as $key => $value) {
               if (is_string($value) && preg_match('/(SELECT|UNION|PG_SLEEP|OR\s+\d+=\s*SELECT)/i', $value)) {
                   throw new \RuntimeException('Malicious input detected');
               }
           }
           return $handler->handle($request);
       }
   }
   

4. TYPO3-Konfiguration anpassen:
   Füge in LocalConfiguration.php eine zusätzliche Security-Ebene hinzu:

   $GLOBALS['TYPO3_CONF_VARS']['SYS']['security'] ??= [];
   $GLOBALS['TYPO3_CONF_VARS']['SYS']['security']['enforceAllRequestsTrusted'] = true;
   

5. Cache leeren & Tools nutzen:

   • $ php typo3/cli_dispatch.phpsh.php extbase:shorthandinstall
   • Nutze Tools wie TYPO3 Security Scan

3. Betroffene TYPO3 Extension nennen¶

Da der Stacktrace noch nicht eindeutig eine konkrete Extension zeigt, gehen wir davon aus, dass:

Core-basiert war (bis auf manuelle Erweiterung):¶

❌ Keine spezifische Extension identifizierbar, da der Fehler im Core-Aufrufweg liegt.

Aber folgende Erweiterungen könnten verdächtig sein:

• Erweiterungen mit eigenen Controllers, die keine saubere Validierung von $_GET['action'] oder $_GET['controller'] durchführen (z. B. news, store, shopligt).
• Eigen-Entwicklungen, die direkte SQL-Abfragen ohne PDO-Parameterbindung starten.

🔍 Empfohlene Vorgehensweise zur Identifikation:
Suche im Projektverzeichnis nach:

grep -r "\$_GET\|GeneralUtility::_GET" public/
grep -r "parseFromViewTuple\|new DateTime\|strptime" Packages/

→ Gibt Ausschlagreiche Dateien heraus, die unsichere Datums-Parsing-Routinen enthalten könnten.

4. Confidence (0–100%)¶

✅ Confidence: 90%

Der Stacktrace zeigt klar Core-Middleware-Aufrufe, aber der Ausgangspunkt liegt im ersten Frame (index.php:21) – also wahrscheinlich vor dem Core-geschützten Bereich. Die Fehlermeldung stammt also aus einem Punkt, wo der Input noch nicht ordnungsgemäß gefiltert wurde.

Die Wahrscheinlichkeit, dass eine Extension dennoch verantwortlich ist (z. B. news, commerce, shopligt), ist hoch – aber konkret kann dies nur durch gezielte Suche im Codebase bestimmt werden.

Bonus-Tipps zur Prävention¶

• Setze SQL-Logging aktiv ($GLOBALS['TYPO3_CONF_VARS']['SYS']['sqlDebugging'] = true;)
• Verwende stets PDO-basierte Queries mit :binding
• Setze fail2ban oder WebApplicationFirewall (z. B. ModSecurity Ruleset für OWASP CRS)
• Regelmäßige Updates von TYPO3 + Erweiterungen

Lass mich wissen, wenn du mir den Inhalt von /public/index.php zwischen Zeile 15–25 zeigst – dann kann ich dir exakt sagen, was manipuliert wurde.