www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/ae162424-05f3-4736-a1a7-bdf08028acf5/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException: An exception occurred while executing a query: Incorrect string value: '\x…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Primäre Ursache: Ungültige UTF-8 Byte-Sequenzen (Overlong Encodings) im Input, die in die Spalte booking_url geschrieben werden sollen.

Detail-Analyse des Byte-Fehlers:
Der Fehler Incorrect string value: '\\xC0\\xA7\\xC0\\xA2%2...' zeigt zwei klassische UTF-8 Overlong Encodings:

• 0xC0 0xA7 → Overlong Encoding für ' (Single Quote, U+0027) – korrekt wäre 0x27.
• 0xC0 0xA2 → Overlong Encoding für " (Double Quote, U+0022) – korrekt wäre 0x22.
• %2... → Deutet auf URL-Encoding hin (z. B. %27 = ', %22 = ").

Warum knallt es genau hier?

1. Datenbank: Die Tabelle/Spalte nutzt utf8mb4 (Standard seit TYPO3 v10+). MySQL utf8mb4 lehnt Overlong Encodings strikt ab (Security Feature gegen SQLi/Filter-Umgehung).
2. Herkunft der Daten: Die Spalte booking_url impliziert, dass hier eine URL (wahrscheinlich Referrer, Landingpage oder Callback-URL) geloggt oder gespeichert wird.
3. Angriffsvektor / Quelle: Ein Client (Bot, Scanner, Browser-Extension) sendet manipulierte Header (Referer, User-Agent, X-Forwarded-For) oder Query-Parameter, die diese verbotenen Byte-Sequenzen enthalten.
4. Fehlende Validierung: Der schreibende Code (Extbase Repository, Doctrine DBAL Connection, oder INSERT Query) validiert/sanitized den Input nicht auf gültiges UTF-8 vor dem Schreiben.

Warum der Stacktrace nur Core zeigt:
Der Fehler passiert im Shutdown-Prozess oder in einem Middleware/Listener nach dem eigentlichen Controller. Der Stacktrace bricht ab, sobald die Exception geworfen wird (in AbstractApplication::run / MiddlewareDispatcher). Der eigentliche Verursacher (deine Extension/Controller/Service) ist im Callstack bereits "vorbei" oder läuft asynchron (z. B. ext:booking, ext:sf_event_mgt, ext:powermail Logging, Tracking-Pixel).

2. Fix beschreiben (konkret)¶

Du musst an der Schreibstelle (Repository / Service / Model Setter) sicherstellen, dass der String valides UTF-8 ist, bevor er an die DB geht.

Option A: Zentrale Sanitization im Model/Setter (Empfohlen für Extbase)¶

// In deinem Model (z. B. \Vendor\Ext\Domain\Model\Booking)
public function setBookingUrl(string $bookingUrl): void
{
    // 1. Overlong Encodings & invalid UTF-8 entfernen/ersetzen
    // ENT_SUBSTITUTE ersetzt ungültige Sequenzen durch  (U+FFFD)
    $clean = mb_convert_encoding($bookingUrl, 'UTF-8', 'UTF-8');
    
    // Alternative strikt: Exception werfen oder leeren String setzen
    // if (!mb_check_encoding($bookingUrl, 'UTF-8')) { $clean = ''; }

    // 2. Optional: URL-Validierung (da Spalte booking_url heißt)
    // $clean = GeneralUtility::sanitizeLocalUrl($clean); // Nur relative URLs
    // oder filter_var($clean, FILTER_VALIDATE_URL);

    $this->bookingUrl = $clean;
}

Option B: Database Layer (Doctrine DBAL Connection Wrapper) – Global sicher¶

Erstelle einen Doctrine\DBAL\Driver\Middleware oder nutze Connection Event Listener (postConnect/executeStatement).
Besser: Nutze GeneralUtility::fixMySQLutf8mb4() falls verfügbar (gibt es in Core nicht public, aber Logik ist trivial):

// Helper in deiner Extension: Classes/Utility/DatabaseUtility.php
public static function sanitizeForDb(string $input): string
{
    // Entfernt Overlong Sequenzen, Surrogate Paare, Non-Characters
    // iconv ist oft schneller/robuster als mbstring für "Reparatur"
    return @iconv('UTF-8', 'UTF-8//IGNORE//TRANSLIT', $input) ?: '';
    // Oder strikt:
    // return mb_check_encoding($input, 'UTF-8') ? $input : '';
}

Anwendung: In jedem Repository/Command/Service vor persist() / executeStatement().

Option C: Middleware (Frühzeitiger Schutz)¶

In Configuration/RequestMiddlewares.php eine Middleware vor NormalizedParamsAttribute registrieren, die $_SERVER['HTTP_REFERER'], $_GET, $_POST bereinigt.
Nachteil: Beeinträchtigt ggf. legitime Logs/Sicherheitsanalysen (WAF/IDS sehen den Angriff dann nicht mehr).

3. Betroffene TYPO3 Extension nennen¶

Nicht exakt bestimmbar aus dem Log, da der Stacktrace nur Core-Middleware zeigt.

Top-Kandidaten basierend auf Spaltennamen booking_url:

1. sf_event_mgt (sehr verbreitet, hat Booking/Registration, loggt Referrer/URLs)
2. events2 / calendarize (Booking-Funktionen)
3. powermail / form (wenn Booking per Formular + Tracking)
4. ke_booking, tp_booking, booking (TER Extensions)
5. Eigene Sitepackage/Projekt-Extension (site_package, project_base, my_extension) mit eigenem Booking-Modul/Tracking.

Wie du sie findest:

# Suche nach der Spalte in ext_tables.sql / Migrations / Models
grep -r "booking_url" /var/www/html/public/typo3conf/ext/ --include="*.sql" --include="*.php" --include="*.xml"
# Suche nach INSERT/UPDATE auf die Tabelle
grep -r "booking_url" /var/www/html/public/typo3conf/ext/ --include="*.php" | grep -i "insert\|update\|setBookingUrl\|createQuery"

4. Confidence (0-100%)¶

95%

• 100% dass die Ursache Overlong UTF-8 Encoding (0xC0 0xAF etc.) in Input-Daten ist, die MySQL utf8mb4 korrekt ablehnt.
• 95% dass die Schreibstelle in einer Extension mit Booking-Funktionalität liegt (Spaltenname booking_url ist sehr spezifisch).
• 5% Unsicherheit nur, ob es ein Core-Logging-Mechanismus ist (unwahrscheinlich, Core loggt keine booking_url), oder eine sehr exotische Extension.

Sofort-Maßnahme (Hotfix für Produktion)¶

Füge in typo3conf/AdditionalConfiguration.php oder ext_localconf.php deines Sitepackages einen Globalen DBAL Event Listener ein, der alle Strings vor dem Execute bereinigt (Performance-Impact vernachlässigbar, Sicherheit hoch):

// typo3conf/AdditionalConfiguration.php
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;

$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['wrapperClass'] = 
    \MyVendor\MySitepackage\Database\SafeUtf8Connection::class;

// Oder per Event Listener (sauberer):
// Services.yaml
// MyVendor\MySitepackage\EventListener\SanitizeDbInputListener:
//   tags:
//     - name: event.listener
//       identifier: 'sanitize-db-input'
//       event: TYPO3\CMS\Core\Database\Event\AlterTableDefinitionStatementsEvent
//       # Besser: Doctrine DBAL Middleware via ConnectionFactory

Einfacher Quick-Fix (ohne Compile/Deploy):
Patch die betroffene Extension direkt im Model Setter (Option A) und deploye. Das ist der sauberste Fixpunkt.