prefiks tabel

Prefiks tabel to przedrostek dodawany przez WordPress do nazw wszystkich tabel w bazie danych. Ustawia się go w pliku wp-config.php zmienną $table_prefix, a domyślna wartość to wp_ ^[1]. Dlatego podstawowe tabele nazywają się zwykle wp_posts, wp_users czy wp_options. Zmiana prefiksu na nietypowy jest popularnym zaleceniem utwardzania (hardening), ale nie usuwa żadnej luki. Utrudnia jedynie część gotowych ataków, które zakładają domyślne nazwy tabel ^[2].

Jak działa

Rdzeń nie wpisuje nazw tabel na sztywno. Obiekt $wpdb przechowuje przypisany prefiks w polu $wpdb->prefix, a nazwy tabel udostępnia jako pola, na przykład $wpdb->posts dla tabeli wpisów ^[3]. W sieci Multisite pole $wpdb->base_prefix zawiera prefiks z wp-config.php bez dopisanego numeru witryny ^[3]. Kod, który korzysta z tych pól, działa przy każdym prefiksie.

Dokumentacja pozwala używać w prefiksie tylko cyfr, liter i podkreśleń ^[1]. Unikalne prefiksy umożliwiają też kilka instalacji w jednej bazie; dokumentacja przypomina wtedy o bezpieczeństwie ^[1]. Taki układ oznacza, że wszystkie strony korzystają zwykle z tego samego użytkownika bazy. Błąd w jednej z nich daje wtedy dostęp do tabel pozostałych, niezależnie od tego, jak różne mają prefiksy. Z punktu widzenia bezpieczeństwa lepiej, by każda strona miała osobną bazę i osobne konto z uprawnieniami tylko do niej.

$table_prefix = 'k7q_';

Prefiks nie kończy się na nazwach tabel. WordPress wbudowuje go także w nazwy niektórych wpisów w bazie. Klucz opcji z definicjami ról powstaje z prefiksu i ciągu user_roles ^[4]. Klucze metadanych użytkownika z jego uprawnieniami i poziomem powstają z prefiksu i ciągów capabilities oraz user_level ^[5].

W WordPressie

Instalator pyta o prefiks, więc najtańszy moment na jego zmianę to nowa instalacja. Sekurak w poradniku z 2017 roku uznaje zmianę domyślnego prefiksu tabel za dobrą praktykę przy instalacji ^[6]. Dokumentacja WordPressa uzasadnia to tym, że wiele opublikowanych ataków SQL injection wymierzonych w WordPressa zakłada domyślny prefiks wp_; jego zmiana może zablokować przynajmniej część z nich ^[2]. Sens ma tylko prefiks trudny do odgadnięcia. Przedrostek utworzony z nazwy domeny albo firmy, na przykład example_, atakujący sprawdzi jako jeden z pierwszych, więc lepiej wybrać kilka przypadkowych znaków zakończonych podkreśleniem.

Zmiana na działającej stronie wymaga więcej niż edycji jednej linii. Trzeba zmienić nazwy wszystkich tabel, zaktualizować wp-config.php oraz poprawić wpisy w tabelach opcji i metadanych użytkowników, w których prefiks jest zapisany w nazwach kluczy ^[7]. Pominięcie ostatniego kroku sprawia, że WordPress nie odczyta ról, bo szuka ich pod kluczami zbudowanymi z nowego prefiksu ^{[4] [5]}. Kolejność pokazuje schemat poniżej.

RYS. 1Zmiana prefiksu na działającej stronie

Operację najlepiej przećwiczyć w środowisku testowym, po wykonaniu pełnej kopii zapasowej (backup). Poradnik firmy hostingowej SEOHOST.pl odradza zmianę na starej, działającej stronie osobom niepewnym swoich umiejętności w SQL, bo ryzyko awarii przewyższa według autorów potencjalny zysk ^[7].

Znaczenie i ograniczenia

Zmiana prefiksu to przykład security through obscurity. Ukrywa nazwę zasobu, ale nie zmienia tego, czy podatność istnieje. Poradnik SEOHOST.pl zauważa, że atakujący z pełną możliwością wykonywania zapytań SQL może po prostu wylistować tabele poleceniem SHOW TABLES ^[7].

Ogólną zasadę opisuje NIST w wytycznych bezpieczeństwa serwerów. Zasada otwartego projektu mówi, że bezpieczeństwo systemu nie powinno zależeć od tajności implementacji ani jej składników ^[8]. Te same wytyczne opisują obronę w głąb: pojedynczy mechanizm zwykle nie wystarcza, a zabezpieczenia należy układać warstwami, tak by przełamanie jednego nie wystarczyło do przejęcia systemu ^[8]. Nietypowy prefiks może być jedną z takich warstw, pod warunkiem że nie zastępuje pozostałych. Prefiks można więc traktować jako drobne utrudnienie dla zautomatyzowanych exploitów, a nie jako zabezpieczenie.

Jak się bronić

Przyczyną jest zawsze błąd w kodzie, najczęściej podatność we wtyczce, która składa zapytanie z danych użytkownika. Dokumentacja klasy wpdb wymaga, by wszystkie niezaufane wartości w zapytaniu SQL były zabezpieczone przed wykonaniem, i wskazuje do tego metodę prepare() ^[3]. To odpowiednik zapytania parametryzowanego.

$wpdb->get_row( $wpdb->prepare(
    "SELECT * FROM {$wpdb->users} WHERE user_login = %s",
    $login
) );

Przykład korzysta też z pola $wpdb->users, więc działa przy dowolnym prefiksie ^[3]. NIST opisuje też zasadę najmniejszych uprawnień: każde zadanie, proces i użytkownik dostaje minimum praw potrzebnych do pracy, co ogranicza szkody po przejęciu ^[8]. W praktyce oznacza to użytkownika bazy bez uprawnień administracyjnych do serwera baz danych. Obok tego liczą się aktualizacje wtyczek, osobny użytkownik bazy dla każdej strony oraz utwardzanie pliku wp-config.php, w którym zapisany jest zarówno prefiks, jak i hasło do bazy.

Skutki udanego ataku

Jeśli wstrzyknięcie SQL się powiedzie, prefiks nie ogranicza szkód. Atakujący może odczytać skróty haseł z tabeli użytkowników albo dopisać sobie uprawnienia w metadanych, tworząc nieautoryzowane konto administratora. Struktura ról opisana w haśle role i uprawnienia użytkowników mieszka w tej samej bazie, pod kluczami z tym samym prefiksem ^{[4] [5]}.