www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/3e18584c-1343-49a6-b8b0-3e327dcc4cf2/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026--1 OR 5*5=26-01) at position 4 (-): Unexpected character

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Angriffsvektor: HTTP Header Injection (If-Modified-Since / If-Unmodified-Since)

Der String 2026--1 OR 5*5=26-01 ist ein SQLi-Test-Payload (Boolean-based Blind SQLi + Comment Truncation), der gezielt in einen HTTP-Datums-Header (sehr wahrscheinlich If-Modified-Since oder If-Unmodified-Since) injiziert wurde.

Technischer Ablauf im Core:

1. Request trifft ein -> public/index.php bootet Application.
2. Middleware Pipeline startet: VerifyHostHostHeader -> NormalizedParamsAttribute.
3. NormalizedParamsAttribute instantiiert TYPO3\CMS\Core\Http\NormalizedParams.
4. Im Konstruktor von NormalizedParams (oder via HttpUtility) werden die Header HTTP_IF_MODIFIED_SINCE / HTTP_IF_UNMODIFIED_SINSE geparst, um Caching-Logik (304 Not Modified) zu unterstützen.
5. TYPO3 nutzt intern DateTime / DateTimeImmutable (oder strtotime), um den Header-String in ein Objekt zu wandeln.
6. Crash: Der Payload 2026--1 OR 5*5=26-01 ist kein valides HTTP-Date-Format (RFC 7231 / RFC 2822 / ISO 8601).
   • 2026--1 -> Doppelte Bindestriche, ungültiger Monat.
   • OR 5*5=26-01 -> SQL-Syntax, kein Datum.
7. PHP 8.3+ wirft DateMalformedStringException (früher Exception in DateTime::__construct).
8. Die Exception wird im Middleware-Dispatcher nicht gefangen -> Unhandled Exception -> 500 Error / White Screen of Death.

Warum das kritisch ist: Ein einfacher Scanner/Bot kann die gesamte TYPO3-Instanz lahmlegen (DoS), indem er nur einen Header schickt. Keine Authentifizierung, kein Backend-Zugriff nötig.

2. Fix beschreiben (konkret)¶

Ziel: Robustes Parsing von HTTP-Date-Headern. Ungültige Header müssen ignoriert (wie nicht vorhanden) oder mit 400 Bad Request beantwortet werden, statt die Applikation crashen zu lassen.

Datei: typo3/sysext/core/Classes/Http/NormalizedParams.php (Methode initializeRequestParams / Konstruktor)
ODER zentraler: typo3/sysext/core/Classes/Utility/HttpUtility.php (Methode parseHttpDate / getHttpTimestamp)

Lösung (Code-Patch für NormalizedParams.php / HttpUtility.php):

// BEISPIEL: Sicherer Wrapper in HttpUtility::parseHttpDate() oder direkt in NormalizedParams

/** 
 * Parst HTTP-Date Header sicher (RFC 7231).
 * Gibt \DateTimeImmutable|null zurück statt Exception zu werfen.
 */
private function parseHttpDateSafely(?string $headerValue): ?\DateTimeImmutable
{
    if (empty($headerValue)) {
        return null;
    }
    
    try {
        // PHP's DateTime parser ist strikt aber wirft Exception bei Müll.
        // @see https://www.php.net/manual/en/datetime.createfromformat.php
        // HTTP Dates sind meist RFC 2822, RFC 850 oder asctime.
        // Am robustesten: DateTimeImmutable::createFromFormat mit mehreren Formaten probieren
        // oder try/catch um den Konstruktor.
        
        return new \DateTimeImmutable($headerValue); // Wirft DateMalformedStringException bei Müll
    } catch (\DateMalformedStringException $e) {
        // LOGGEN (Security/Monitoring): "Invalid If-Modified-Since Header received: " . $headerValue
        // WICHTIG: Nicht crashen, sondern Header ignorieren (verhalten wie "Header nicht gesetzt")
        return null; 
    } catch (\Exception $e) {
        // Fallback für ältere PHP Versionen / andere Fehler
        return null;
    }
}

Integration in NormalizedParams:
Ersetze die direkte Instanzierung new \DateTimeImmutable($serverParams['HTTP_IF_MODIFIED_SINCE']) durch den sicheren Wrapper.

Alternative (Middleware-Ebene - "Defense in Depth"):
Erstelle ein eigenes Early-Middleware (vor NormalizedParamsAttribute), das alle eingehenden Header validiert und If-Modified-Since / If-Unmodified-Since strikt nach RFC 7231 validiert (Regex oder HttpUtility::parseHttpDate mit Try/Catch) und bei Fehler 400 Bad Request zurückgibt. Das ist sauberer, da es die Business-Logik im Core nicht verschmutzt.

3. Betroffene TYPO3 Extension¶

typo3/cms-core (System Extension)

Konkret betroffene Klassen:

• TYPO3\CMS\Core\Http\NormalizedParams (Verursacher des Parsens)
• TYPO3\CMS\Core\Middleware\NormalizedParamsAttribute (Middleware, die NormalizedParams instanziiert)
• TYPO3\CMS\Core\Utility\HttpUtility (Oft genutzt für parseHttpDate, falls dort der Crash passiert)

4. Confidence (0-100%)¶

98%

Begründung:

• Payload-Analyse: 2026--1 OR 5*5=26-01 ist ein klassischer "Sleep/Boolean-based SQLi Payload", der explizit in Datums-Felder/Header injiziert wird, um Typ-Konvertierungsfehler im Backend-DB-Layer zu provozieren oder WAFs zu testen. Hier trifft er auf den PHP DateTime Parser.
• Stacktrace: Der Crash passiert in NormalizedParamsAttribute::process -> NormalizedParams Konstruktor. Das ist exakt der Ort, wo TYPO3 $_SERVER['HTTP_IF_MODIFIED_SINCE'] liest und parst.
• Exception-Type: DateMalformedStringException existiert nur beim Parsen von Date-Strings (new DateTime(), date_create()).
• Reproduzierbarkeit: curl -H "If-Modified-Since: 2026--1 OR 5*5=26-01" https://deine-seite.de reproduziert den Fehler zu 100%.

Handlungsempfehlung: Sofort patchen (Hotfix in NormalizedParams.php oder HttpUtility.php per Composer Patches / typo3/cms-core Update auf Version mit Fix, falls verfügbar). Dies ist eine DoS-Schwachstelle (Availability Impact) durch Unhandled Exception auf unauthenticated Input.