www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/41320f65-4592-4b00-9762-6e749546072f/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

TYPO3\CMS\Extbase\Mvc\Exception\InvalidControllerNameException: The controller "Event" AND EXTRACTVALUE(2295,CONCAT(0x7e,((SELECT (ELT(2295=2295,1)))…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Die Fehlermeldung belegt einen SQL-Injektionsversuch über das controller-Request-Parameter, kombiniert mit einer fehlenden bzw. inkonfigurierten Whitelist in der TYPO3-Extension.

• Der angeforderte Controller-Name enthält den Roheintrag:
  Event AND EXTRACTVALUE(2295,CONCAT(0x7e,((SELECT (ELT(2295=2295,1)))),0x7e))-- -
• Dieser Pattern ist ein klassischer MySQL error-based Injection Payload. ELT(2295=2295,1) gibt 1 zurück, wenn die Bedingung wahr ist, und EXTRACTVALUE versucht daraufhin, von diesem Wert XML zu extrahieren – ein known Trigger für MySQL-Fehler, um Daten auszuschleusen oder das DB-Verhalten zu beeinflussen.
• Die Exception TYPO3\CMS\Extbase\Mvc\Exception\InvalidControllerNameException wird von TYPO3s Routing-Layer geworfen, weil die Plugin-Konfiguration (Calendarlist) den Controller-Namen nicht aus der ext_localconf.php Whitelist erwartet. Da der Parameter jedoch roh aus der URL übernommen wurde, landet der gesamte Injection-String in der Fehlermeldung – das Framework hat die Kontrolle über den Parameter noch nicht bereinigt, bevor er in String-Kontext gelangt.

Zusammenfassend: Die Extension Calendarlist unterbindet den Angriff an der Routing-Ebene (weshalb die Exception kommt), aber die Wurzel liegt in der fehlenden Validierung/Whitelist-Konfiguration und der Tatsache, dass request-Parameter späterere Teile der Extension (z.B. SQL-Queries, dynamische Konfiguration) erreichen könnten, wenn die Konfiguration fehlscht oder bypassed wird.

2. Fix beschreiben (konkret)¶

1. Whitelist in ext_localconf.php ergänzen:
   Fügen Sie allen berechtigten Controllern und Aktionen des Plugins explizit ein. Beispiel:

   \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
       'Vendor/Calendarlist', // Extension Key
       'Calendarlist',         // Plugin Name
       [
           'Event' => ['index', 'show', 'list', 'create', 'edit'],
           // Alle weiteren gültigen Controller auflisten
       ],
       \TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_PERM_MODE_ALL
   );
   

   Dies verhindert, dass beliebige Strings als Controller akzeptiert werden.

2. Request-Parameter validieren/sanitisieren:
   Falls die Extension den controller-Parameter für beliebige Abläufe nutzt (z.B. dynamisches Laden von Modellen, SQL-Interpolation), ersetzen Sie jede direkte String-Konkatänation durch:

   • Extbase-Repositories (nutzen automatisch vorbereitete Statements).
   • Falls Roh-SQL nötig ist: Nutzung von GeneralUtility::prepareJDBCString() oder Doctrine DBAL prepare().
   • Nutzen Sie $request->getArgument('controller', NULL, TRUE) mit dem dritten Parameter TRUE für Auto-Sanitization (falls TYPO3 Version & Setup dies unterstützt).

3. Error-Handling anpassen:
   In config (AdditionalConfiguration.php):

   'debugExceptionHandling' => 0,
   

   Vermeiden Sie, dass fertige Rohparameter in Exception-Nachrichten landen (wichtig für Production-Sicherheit).

3. Betroffene TYPO3 Extension¶

Extension: Calendarlist (Plugin Name im Fehlerbild ebenfalls Calendarlist).
Es wird empfohlen, das konkrete Extension-Key-Verzeichnis (typo3conf/ext/Calendarlist/ oder über Composer vendor/...) zu prüfen und die ext_localconf.php sowie die Route-/Controller-Logik zu reviewen.

4. Confidence (0-100%)¶

94%

• Der Payload-Struktur (EXTRACTVALUE/ELT/-- -) und der Platzierung im controller-Parameter entspricht exakt bekannten TYPO3-Extbase-Injektionsvektoren.
• Die Exception stammt direkt aus dem Core (InvalidControllerNameException), was bestätigt, dass der Parameter routingspezifisch verarbeitet wird.
• Das Fehlen einer korrekten configurePlugin()-Konfiguration ist die häufigste Ursache für derartige "Controller not allowed"-Fehler in TYPO3.
• Restliches Restrisiko (5%): Es könnte sein, dass die Injection bereits tiefer im Code der Extension stattgefunden hätte, wenn die Exception nicht frühzeitig durch das Routing geworfen worden wäre – jedoch deutet die frühzeitige Throwsituation darauf hin, dass das Framework das Eindringen bisher verhindert hat.