www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/699e8e82-313f-449f-8ced-1cdd7b3a9eb9/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¶

Es handelt sich um einen SQL-Injection-Angriffsversuch (Blind/Time-based), der in eine DateMalformedStringException mündet.

• Der Payload: 2026--1')) OR 5*5=26 -- -01
• Der Kontext: Der Request erreicht den VerifyHostHeader-Middleware (/vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php:55) sehr früh im Bootstrap-Prozess (vor dem Routing/Controller).
• Der Mechanismus: Der Angreifer manipuliert einen HTTP-Header (höchstwahrscheinlich Host, X-Forwarded-Host oder einen Custom-Header, der für Datumslogik missbraucht wird), sodass der Wert wie ein Datum aussieht, aber SQL-Injection-Syntax enthält (-- für Kommentar, OR 5*5=26 für logische Prüfung).
• Der Crash: TYPO3 versucht irgendwo vor oder innerhalb der Middleware-Kette (wahrscheinlich beim Parsing von EXPIRE/LIFETIME Cookies, Last-Modified Headern oder einem Custom-Header-Wert), diesen String via DateTime::__construct() oder strtotime() zu parsen. Der Double-Hyphen -- (SQL-Kommentar) bricht das Datumsformat (2026--1...) -> DateMalformedStringException bei Position 4.
• Warum VerifyHostHeader? Dieser Middleware validiert den Host-Header gegen $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern']. Wenn der Header manipuliert ist (z.B. example.com'; DROP TABLE ... oder hier der Datums-Payload), kann die Validierung oder das anschließende Logging/Processing den Wert in einen Datetime-Parser werfen.

Kernproblem: Unvalidierte User-Input (HTTP Header) gelangt in einen strikten Datetime-Parser, bevor die Applikation sauber bootet. Die Exception wird nicht abgefangen, weil sie im Middleware-Stack (PSR-15) vor dem globalen Error-Handler/Exception-Handler auftritt, der ein schönes 500-Template rendern würde.

2. Fix beschreiben (konkret)¶

Da der Fehler im Core-Middleware-Stack (VerifyHostHeader, NormalizedParamsAttribute) auftritt, ist keine Extension der Verursacher, sondern ein Core-Handling-Problem bei schmutzigen Headern.

Sofortmaßnahme (Server/Infrastruktur - Empfohlen):
Blockiere den Request vor PHP/TYPO3 (WAF, ModSecurity, Nginx/Apache Config).

• Nginx Beispiel:

  # Blockiere SQLi-Pattern in Host-Header früh
  if ($http_host ~* "(\-\-|\b(OR|AND)\b.*=.*)") {
      return 403;
  }
  # Oder generell: Host-Header Validierung auf erlaubte Domains beschränken
  # (TYPO3 trustedHostsPattern macht das, aber erst *in* PHP)
  

TYPO3-Core Fix / Workaround (falls WAF nicht möglich):
Erstelle einen eigenen, frühestmöglichen Middleware (via Configuration/RequestMiddlewares.php in typo3conf oder Sitepackage), der vor VerifyHostHeader greift und Exception-Sicherheit bietet.

Datei: typo3conf/Configuration/RequestMiddlewares.php (oder config/request_middlewares.php je TYPO3 Version)

<?php
return [
    'frontend' => [
        'early-security-sanitizer' => [
            'target' => \Vendor\SitePackage\Middleware\EarlySecuritySanitizer::class,
            'before' => ['verifyhostheader'], // WICHTIG: Vor VerifyHostHeader
        ],
    ],
];

Middleware Implementation (Classes/Middleware/EarlySecuritySanitizer.php):

<?php
declare(strict_types=1);

namespace Vendor\SitePackage\Middleware;

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;
use TYPO3\CMS\Core\Http\ResponseFactory;

class EarlySecuritySanitizer implements MiddlewareInterface
{
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        try {
            // 1. Host Header validieren/sanitizen VOR Core-Logik
            $host = $request->getHeaderLine('Host');
            if ($this->looksLikeSqlInjection($host)) {
                // Loggen, aber nicht crashen
                // \TYPO3\CMS\Core\Log\LogManager::getLogger(__CLASS__)->warning('Blocked SQLi in Host header', ['host' => $host]);
                return (new ResponseFactory())->createResponse(400)->withBody(
                    (new \TYPO3\CMS\Core\Http\StreamFactory())->createStream('Bad Request')
                );
            }

            // 2. Andere kritische Header prüfen (X-Forwarded-Host, X-Forwarded-For, etc.)
            // ...

        } catch (\Throwable $e) {
            // Failsafe: Auf keinen Fall Exception nach oben bubbeln lassen
            return (new ResponseFactory())->createResponse(500)->withBody(
                (new \TYPO3\CMS\Core\Http\StreamFactory())->createStream('Internal Server Error')
            );
        }

        return $handler->handle($request);
    }

    private function looksLikeSqlInjection(string $value): bool
    {
        // Einfache Heuristik für die gängigsten Payloads in Headern
        $patterns = [
            '/\-\-/',           // SQL Comment
            '/\b(OR|AND)\b\s*.*=.+/i', // OR 1=1, OR 5*5=26
            '/union\s+select/i',
            '/sleep\s*\(/i',
            '/benchmark\s*\(/i',
        ];
        foreach ($patterns as $pattern) {
            if (preg_match($pattern, $value)) {
                return true;
            }
        }
        return false;
    }
}

Zusätzlich: trustedHostsPattern prüfen (Settings.php / AdditionalConfiguration.php)
Stelle sicher, dass das Pattern strikt ist (kein .*).

$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = '^example\\.com$|^www\\.example\\.com$';

3. Betroffene TYPO3 Extension nennen¶

Keine projekt-spezifische Extension.
Betroffen ist der TYPO3 Core (typo3/cms-core), speziell die Middleware-Kette:

1. TYPO3\CMS\Core\Middleware\VerifyHostHeader
2. TYPO3\CMS\Core\Middleware\NormalizedParamsAttribute
3. Der zugrundeliegende Datetime-Parser (PHP DateTime / DateTimeImmutable), der durch einen manipulierten Header-Wert (vermutlich Host, Date, If-Modified-Since oder ein Custom-Header) gefüttert wird.

Hinweis: Wenn du eine Extension hast, die sehr früh einen Middleware registriert (z.B. für Auth, Tracking, GeoIP) und dort Header parst, wäre diese Extension der Verursacher. Basierend auf dem Stacktrace (reine Core-Middlewares) ist es aber ein Core-Verhalten bei böswilligen Requests.

4. Confidence (0-100%)¶

95%

• Begründung: Der Exception-String Failed to parse time string (2026--1')) OR 5*5=26 -- -01) ist ein klassisches SQLi-Payload-Muster (Time-based Blind SQLi Test: 5*5=26 prüft Wahrheitswert, -- kommentiert Rest aus). Der Stacktrace zeigt reinem Core-Middleware-Flow ohne Custom-Code. Die Exception entsteht, weil PHP's DateTime Parser auf den injizierten String losgelassen wird, bevor TYPO3's Error Handling greift.
• Restunsicherheit (5%): Minimale Chance, dass eine per ext_localconf.php registrierte sehr frühe Middleware (Priority < 100) oder ein config/system/additional.php Code-Snippet den Header vor VerifyHostHeader verarbeitet und den Parser aufruft. Ohne Projekt-Code-Einsicht ist Core-Verhalten die sicherste Annahme.