Contao: Fehlerhafte Zugriffskontrolle im Table Access Voter

Aufgrund eines Caching-Fehlers im Security Voter, der den Zugriff auf Tabellenebene im Data Container (DCA)-Backend von Contao steuert, kann ein Backend-Benutzer mit geringen Rechten (ohne Administratorstatus) unbefugten Lese-, Erstellungs-, Aktualisierungs- und Löschzugriff auf Datenbanktabellen außerhalb seiner zugewiesenen Modulberechtigungen erlangen. Dies umfasst auch Tabellen mit sensiblen personenbezogenen Daten, wie Mitgliedsdatensätze im Frontend und E-Mail-Adressen von Newsletter-Abonnenten.

Details zur Schwachstelle

Das Contao-Backend ist in Module unterteilt (z. B. „Nachrichten“, „Mitglieder“). Jeder Backend-Benutzer ist einer Gruppe zugewiesen, die festlegt, mit welchen Modulen und damit welchen Datenbanktabellen er arbeiten darf. Bevor Contao den Zugriff auf eine Tabelle erlaubt, prüft das System, ob die Benutzergruppe die entsprechende Tabelle enthält.

Um diese Überprüfung nicht fortlaufend zu wiederholen, wird das Ergebnis für die Dauer des HTTP-Requests zwischengespeichert. Dabei wird das Ergebnis jedoch unter einem unzureichenden Bezeichner abgelegt: Statt zu erfassen, ob der Benutzer Zugriff auf eine spezifische Tabelle hat, wird lediglich vermerkt, ob der Benutzer Zugriff auf eine Ressource hat, ohne die konkrete Tabelle festzuhalten.

Wenn in einem Request zuerst eine Tabelle geprüft wird, auf die der Benutzer Zugriff HAT, und anschließend eine abweichende Tabelle, für die KEINE Berechtigung vorliegt, übernimmt Contao das zuvor zwischengespeicherte Ergebnis. Dadurch erhält der Benutzer Zugriff auf eine Tabelle, für die seiner Gruppe keine Rechte gewährt wurden.

Technische Details

Das Contao-Backend erzwingt die Zugriffskontrolle auf Tabellenebene über eine Kette von Symfony Security Votern. Betroffen ist TableAccessVoter::hasAccessToModule() in core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php:

    private array $canAccessTable = [];
    private array $canReadAccessTable = [];
 
    private function hasAccessToModule(TokenInterface $token, ...): bool
    {
        $tokenHash = hash('xxh128', serialize($token));
 
        if (isset($this->canAccessTable[$tokenHash]) || (...)) {
            return $this->canAccessTable[$tokenHash] ?? $this->canReadAccessTable[$tokenHash];
        }
 
        $table = $subject->getDataSource();
 
        foreach ($GLOBALS['BE_MOD'] as $modules) {
            ...
            return $this->canAccessTable[$tokenHash] = true;  // or false
        }
    }

Der Cache-Schlüssel $tokenHash wird ausschließlich aus dem Security Token des aktuellen Benutzers generiert und berücksichtigt die geprüfte Tabelle nicht. Da TableAccessVoter ein gewöhnlicher, geteilter Symfony-Dienst ist, bleibt dieser Cache für die gesamte Dauer eines HTTP-Requests bestehen. Die erste für einen Benutzer in einem Request geprüfte Tabelle bestimmt somit das zwischengespeicherte Ergebnis für alle nachfolgend im selben Request geprüften Tabellen – unabhängig davon, ob dieses Ergebnis für die zweite Tabelle korrekt ist.

Verstärkt wird das Verhalten durch DefaultDataContainerVoter, einen nachrangigen, permissiven Fallback-Voter, der tabellenbezogene Zugriffe gewährt, sofern kein anderer Voter dies explizit verweigert. Wenn TableAccessVoter aufgrund des veralteten Cache-Zustands keine Entscheidung trifft, stuft dieser Fallback-Voter den Zugriff als zulässig ein.

Die meisten Datenbanktabellen in Contao besitzen keine zusätzliche, tabellenspezifische Prüfung. Lediglich tl_content, tl_favorites, tl_form, tl_form_field, tl_module, tl_image_size(_item), tl_job, tl_layout, tl_page, tl_preview_link, tl_undo und tl_user verfügen über eine solche Absicherung. Tabellen wie tl_member (Mitgliederdaten), tl_newsletter_recipients (Abonnenten-E-Mail-Adressen), tl_news, tl_calendar_events, tl_faq und tl_comments stützen sich ausschließlich auf die betroffene Prüfung.

Danksagung

Diese Sicherheitslücke wurde von Sven Jäger der SySS GmbH entdeckt.