Contao: Nieprawidłowa kontrola dostępu w voterze dostępu do tabel

Z powodu błędu buforowania w mechanizmie security voter, kontrolującym dostęp do tabel w Data Container (DCA) panelu administracyjnego Contao, użytkownik zaplecza o niskich uprawnieniach (niebędący administratorem) może uzyskać nieautoryzowany dostęp do odczytu, tworzenia, modyfikacji oraz usuwania danych z tabel bazy danych wykraczających poza uprawnienia przypisanych mu modułów. Obejmuje to tabele zawierające wrażliwe dane osobowe, takie jak konta użytkowników frontendowych oraz adresy e-mail subskrybentów newslettera.

Szczegóły podatności

Panel administracyjny Contao jest zorganizowany w moduły (np. „Aktualności”, „Użytkownicy”). Każdy użytkownik zaplecza jest przypisany do grupy, która określa, z którymi modułami, a tym samym tabelami bazy danych, może pracować. Zanim Contao zezwoli na operację na danej tabeli, weryfikuje, czy grupa użytkownika posiada do niej uprawnienia.

Aby uniknąć wielokrotnego powtarzania tego sprawdzenia, Contao zapamiętuje wynik na czas trwania żądania HTTP. Problem polega na tym, że wynik jest zapisywany pod niewłaściwym identyfikatorem: zamiast zapamiętać, czy użytkownik ma dostęp do konkretnej tabeli X, system rejestruje jedynie ogólny fakt posiadania dostępu do zasobu, bez wskazania docelowej tabeli.

W rezultacie, jeśli w ramach jednego żądania najpierw sprawdzana jest tabela, do której użytkownik MA dostęp, a następnie inna tabela, do której uprawnień NIE POSIADA, Contao ponownie wykorzystuje wcześniejszą odpowiedź. Użytkownik uzyskuje w ten sposób dostęp do tabeli, do której jego grupa nie miała uprawnień.

Szczegóły techniczne

Panel administracyjny Contao egzekwuje kontrolę dostępu na poziomie tabel poprzez łańcuch voterów bezpieczeństwa Symfony. Kluczowym elementem jest TableAccessVoter::hasAccessToModule() w 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
        }
    }

Klucz pamięci podręcznej, $tokenHash, jest tworzony wyłącznie na podstawie tokena bezpieczeństwa bieżącego użytkownika i nie zawiera nazwy weryfikowanej tabeli. Ponieważ TableAccessVoter jest standardową, współdzieloną usługą Symfony, pamięć ta pozostaje aktywna przez cały czas trwania żądania HTTP. Pierwsza sprawdzona tabela determinuje więc wynik z pamięci podręcznej dla wszystkich kolejnych tabel weryfikowanych w tym samym żądaniu, niezależnie od tego, czy jest on prawidłowy dla kolejnej tabeli.

Sytuację pogarsza DefaultDataContainerVoter, voter pomocniczy o niskim priorytecie, który zezwala na dostęp związany z tabelą, o ile żaden inny voter wyraźnie go nie odrzuci. Kiedy TableAccessVoter zwraca neutralną odpowiedź („brak opinii”) ze względu na nieaktualną pamięć podręczną, voter pomocniczy traktuje to jako pełne przyznanie uprawnień.

Większość tabel bazy danych w Contao nie posiada dodatkowej weryfikacji. Zabezpieczenie takie mają wyłącznie 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 oraz tl_user. Tabele takie jak tl_member (dane członków serwisu), tl_newsletter_recipients (adresy e-mail subskrybentów), tl_news, tl_calendar_events, tl_faq i tl_comments polegają wyłącznie na wadliwym mechanizmie opisanym powyżej.

Podziękowania

Podatność została wykryta przez Svena Jägera z SySS GmbH.