www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/f1b688a4-ed42-4870-aa36-c0baecaf35b9/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026-01-1); waitfor delay '0:0:15' -- -01) at position 9 ()): Unexpected character

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren (Root Cause Analysis)¶

Es handelt sich um einen aktiven Angriffsversuch (Automatisierter Scanner / SQL Injection Probe), der zu einem ungefangenen Exception-Crash führt.

• Der Payload: Der String (2026-01-1); waitfor delay '0:0:15' -- -01) ist ein klassischer Time-Based Blind SQL Injection Payload für Microsoft SQL Server (WAITFOR DELAY).
• Der Vektor: Der Angreifer injiziert diesen Payload in einen HTTP-Header, der von TYPO3 früh im Request-Lifecycle als Datum/Zeit interpretiert wird. Kandidaten sind primär:
  • Date Header
  • If-Modified-Since Header
  • If-Unmodified-Since Header
  • (Seltener) Host / X-Forwarded-Host Header, falls eine Extension diese als Timestamp missbraucht.
• Der Crash-Mechanismus: Im Middleware-Stack (NormalizedParamsAttribute → VerifyHostHeader → evtl. Custom Middleware) wird versucht, den Header-Wert via new \DateTime($headerValue) oder date_create() zu parsen.
• PHP 8.3+ Verhaltensänderung: Seit PHP 8.3 wirft der DateTime-Konstruktor bei ungültigen Strings eine DateMalformedStringException (extends Exception), statt nur false zurückzugeben oder eine Warning zu werfen. Da dies im Middleware-Stack ungefangen bleibt, crasht die Applikation mit HTTP 500.

Warum die Frames VerifyHostHeader / NormalizedParamsAttribute zeigen:
Diese Middlewares laufen sehr früh. NormalizedParamsAttribute normalisiert Server-Parameter (inkl. HTTP-Headers wie HTTP_DATE, HTTP_IF_MODIFIED_SINCE). Der Fehler tritt in oder direkt nach NormalizedParamsAttribute auf (z. B. in einer nachgeschalteten Custom-Middleware, im VerifyHostHeader bei spezieller Konfiguration, oder beim Zugriff auf $normalizedParams->getRequestTime()), der Stacktrace bricht aber genau dort ab, wo die Exception die Middleware-Pipeline verlässt.

2. Fix beschreiben (konkret)¶

Sofortmaßnahme (Workaround / Server-Level):
Blockiere den Request vor PHP/TYPO3 (WAF, ModSecurity, Nginx/Apache Config), wenn Header verdächtige SQL-Keywords (waitfor, delay, benchmark, sleep, --, ;--) enthalten.

Dauerhafter Code-Fix (TYPO3 Core / Extension):
Da der Stacktrace auf Core-Dateien zeigt, aber der Parsing-Fehler likely in Custom Code oder einer 3rd-Party Extension passiert (Core parst Host nicht als Datum), muss der Code gefunden werden, der new \DateTime($header) aufruft.

Fix-Pattern (PHP 8.3+ Safe):

// SCHLECHT (Crash bei Angreifer-Input)
$date = new \DateTime($request->getServerParams()['HTTP_DATE'] ?? '');

// GUT (Robust)
$dateHeader = $request->getServerParams()['HTTP_DATE'] ?? '';
try {
    $date = new \DateTime($dateHeader);
} catch (\DateMalformedStringException $e) {
    // Loggen (Security Audit Log!), Fallback auf Server-Zeit / Ignorieren
    $this->logger->warning('Invalid Date header received (possible attack)', [
        'header' => $dateHeader,
        'ip' => $request->getServerParams()['REMOTE_ADDR'] ?? 'unknown'
    ]);
    $date = new \DateTime(); // Fallback: Now
}

TYPO3 Core Konfiguration prüfen:
Stelle sicher, dass $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] streng gesetzt ist (kein .*), um Host Header Injection generell zu erschweren (auch wenn hier der Date-Header der Vektor war).

3. Betroffene TYPO3 Extension nennen¶

Primär: typo3/cms-core (System-Environment / Middleware Stack)

• Der Crash passiert im Core-Bootstrap (AbstractApplication, MiddlewareDispatcher).
• WICHTIG: Der Core selbst parst keine Date-Header im VerifyHostHeader oder NormalizedParamsAttribute zu DateTime-Objekten (nur Strings/Arrays).
• Schlussfolgerung: Es ist zu 95% eine installierte 3rd-Party Extension (oder AdditionalConfiguration.php / ext_localconf.php Middleware-Registrierung), die eine eigene Middleware vor oder zwischen NormalizedParamsAttribute und VerifyHostHeader (Priorität < 100) registriert hat und dort Header parst.

Verdächtige Extension-Kategorien (Auditieren!):

1. Security / WAF Extensions (z. B. helhum/typo3-secure-web, bitmotion/securebe, t3security Forks) – diese parsen oft Header für Rate-Limiting/Geo-Blocking.
2. Analytics / Tracking Extensions (Loggen Request-Zeit).
3. Caching / Reverse Proxy Extensions (Auslesen von If-Modified-Since für 304 Responses).
4. Custom Sitepackage mit eigener Middleware Registrierung in Configuration/RequestMiddlewares.php.

Befehl zur Suche im Projekt:

grep -r "new \\\\DateTime" --include="*.php" public/typo3conf/ext/ vendor/ | grep -v ".git" | grep -E "(HTTP_|SERVER\['|getHeader|getServerParams)"
# Oder gezielt nach Middleware-Registrierungen:
cat public/typo3conf/ext/*/Configuration/RequestMiddlewares.php 2>/dev/null

4. Confidence (0-100%)¶

95%

• 100%: Erkennung als SQLi-Scanner-Angriff (Payload ist eindeutig).
• 100%: Erkennung als PHP 8.3+ DateMalformedStringException durch ungefangenes Parsen.
• 90%: Lokalisierung auf Custom/3rd-Party Middleware (Core parst Host/Header nicht als Datum an dieser Stelle).
• Abzug 5%: Restunsicherheit, ob evtl. ein sehr spezieller Core-Bug bei NormalizedParams + Date Header + PHP 8.3 vorliegt (eher unwahrscheinlich, Core nutzt strtotime/gmdate defensiv).