role i uprawnienia użytkowników

Role i uprawnienia użytkowników to mechanizm WordPressa, który każdemu kontu przypisuje rolę, a każdej roli zestaw uprawnień (capabilities), takich jak publish_posts, moderate_comments czy edit_users ^[1]. Rola określa, co użytkownik widzi i co może zrobić w panelu; uprawnienie to pojedyncza czynność, na przykład edycja albo publikacja wpisu ^[2]. Jest to wbudowana w WordPressa odmiana RBAC, czyli kontroli dostępu opartej na rolach. Dla bezpieczeństwa strony liczy się przede wszystkim to, ile kont ma najwyższe uprawnienia i czy wtyczki sprawdzają uprawnienia przed wykonaniem akcji.

Jak działa

Gdy użytkownik wysyła żądanie, WordPress najpierw ustala, kim jest (uwierzytelnianie), a następnie, czy wolno mu wykonać daną czynność (autoryzacja). Drugi krok sprowadza się do pytania o konkretne uprawnienie, a nie o nazwę roli. Kod wtyczki lub motywu robi to funkcją current_user_can(), która sprawdza uprawnienia bieżącego użytkownika ^[2]. Dokumentacja dla autorów wtyczek zaleca, by każdą operację na danych przesłanych przez użytkownika, w panelu i na stronie publicznej, wykonywać dopiero po sprawdzeniu uprawnień ^[3].

// Obronny wzorzec: akcja tylko dla użytkowników z uprawnieniem edit_others_posts
if ( current_user_can( 'edit_others_posts' ) ) {
    // wykonanie operacji
}

Role i ich uprawnienia są zapisane w bazie danych, w tabeli opcji pod kluczem user_roles ^[2]. Funkcje add_role() i remove_role() dodają i usuwają role, a add_cap() i remove_cap() zmieniają pojedyncze uprawnienia ^[1]. Ponieważ zmiana trafia do bazy, wystarczy ją wykonać raz: kolejne wywołania add_role() dla istniejącej roli niczego nie zmieniają, nawet listy uprawnień ^[2].

Sprawdzenie uprawnień przy każdym żądaniu pokazuje schemat poniżej.

RYS. 1Sprawdzenie uprawnienia przed akcją

Rodzaje

WordPress ma sześć predefiniowanych ról: superadministrator, administrator, redaktor, autor, współpracownik i subskrybent ^[1]. Dokumentacja zaznacza, że nie należy traktować jednej roli jako starszej od drugiej, lecz jako opis obowiązków w witrynie ^[1].

Kilka uprawnień ma szczególne znaczenie dla bezpieczeństwa. unfiltered_html pozwala zapisywać dowolny HTML i JavaScript; na pojedynczej witrynie mają je administrator i redaktor ^[1]. Uprawnienie unfiltered_upload nie przysługuje domyślnie żadnej roli, nawet superadministratorowi, i wymaga zdefiniowania stałej ALLOW_UNFILTERED_UPLOADS ^[1].

W WordPressie

Rola domyślna i otwarta rejestracja. Ustawienie „Każdy może się zarejestrować” w Ustawieniach ogólnych pozwala każdemu założyć konto w witrynie ^[4]. Rolę nadawaną nowym kontom wybiera się w tym samym miejscu; na liście jest także Administrator ^[4]. Wartość tej opcji przechowuje default_role. Otwarta rejestracja w połączeniu z błędną rolą domyślną daje każdemu gościowi pełną kontrolę nad stroną.

Luki dostępne dla subskrybenta. Subskrybent ma tylko uprawnienie read ^[1], ale jest zalogowany. Jeśli wtyczka wykonuje akcję bez sprawdzenia uprawnienia, każde konto, także subskrybenta, może ją wywołać. Taki błąd to brak kontroli uprawnień (missing authorization); w opisach podatności często pojawia się dopisek o wymaganym poziomie dostępu. Przy otwartej rejestracji poziom subskrybenta jest w praktyce dostępny dla każdego.

Uprawnienia do plików. Stała DISALLOW_FILE_EDIT w pliku wp-config.php działa tak, jakby wszystkim użytkownikom odebrać uprawnienia edit_themes, edit_plugins i edit_files ^[6]. Wyłącza to edytor plików motywów i wtyczek, który dokumentacja opisuje jako częste pierwsze narzędzie napastnika po zalogowaniu ^[6].

Zagrożenia i skutki

MITRE opisuje słabość CWE-269 jako sytuację, w której produkt nie przydziela, nie zmienia, nie śledzi albo nie sprawdza poprawnie uprawnień, tworząc nieprzewidziany zakres kontroli ^[5]. W WordPressie przybiera ona kilka postaci.

• eskalacja uprawnień: subskrybent albo współpracownik uzyskuje uprawnienia administratora przez błąd we wtyczce.
• nieautoryzowane konto administratora: napastnik zakłada nowe konto z pełnymi uprawnieniami, co jest typowym śladem przejęcia strony.
• Nadmiar administratorów: każde konto z rolą administratora może instalować wtyczki ^[1], więc jego przejęcie oznacza przejęcie całej witryny.
• Stored XSS przez unfiltered_html: konto redaktora z tym uprawnieniem może zapisać skrypt, który wykona się w przeglądarce administratora.

Jak się bronić

Podstawą jest zasada najmniejszych uprawnień. MITRE zaleca stosować ją przy przydzielaniu praw dostępu oraz rozdzielać uprawnienia tak, by dostęp wymagał spełnienia kilku warunków ^[5].

• Ograniczyć liczbę administratorów i do codziennej pracy używać ról o mniejszych uprawnieniach ^[7].
• Nie nadawać administratorom nazw użytkownika łatwych do odgadnięcia, takich jak admin czy webmaster ^[6].
• Włączyć uwierzytelnianie dwuskładnikowe (2FA) dla wszystkich administratorów i kont uprzywilejowanych ^[7].
• Wyłączyć rejestrację, jeśli strona jej nie potrzebuje, a przy włączonej sprawdzić, czy rolą domyślną jest subskrybent ^[4].
• Okresowo przeglądać listę użytkowników i usuwać konta nieużywane albo obniżać im rolę ^[7].
• W kodzie własnych wtyczek sprawdzać uprawnienia przez current_user_can() przed każdą operacją ^[3], a nie polegać na tym, że żądanie pochodzi z panelu. Szerzej opisuje to weryfikacja uprawnień.
• Wyłączyć edytor plików stałą DISALLOW_FILE_EDIT ^[6].

Historia i przykłady

WordPress rozwija model ról od wczesnych wersji; obecna dokumentacja wymienia sześć ról i kilkadziesiąt uprawnień w tabeli zestawiającej je z rolami ^[1]. Nowsze funkcje dodają uprawnienia bez zmiany samego modelu: dokumentacja opisuje osobno uprawnienia edytora witryny, dostępnego przy aktywnym motywie blokowym ^[1]. Stałe elementy pozostają te same: administrator tworzony automatycznie przy instalacji ^[1], subskrybent z jednym uprawnieniem read ^[1] i zalecenie, by kod wtyczek sam pilnował uprawnień ^[3].