weryfikacja uprawnień

Weryfikacja uprawnień to sprawdzenie po stronie serwera, czy użytkownik ma prawo wykonać konkretną operację na konkretnym zasobie. Jest to praktyczna postać autoryzacji. W WordPressie służy do tego funkcja current_user_can(), która zwraca informację, czy bieżący użytkownik ma wskazane uprawnienie ^[1]. Brak takiego sprawdzenia MITRE opisuje jako słabość CWE-862: produkt nie wykonuje kontroli autoryzacji, gdy ktoś próbuje uzyskać dostęp do zasobu lub wykonać działanie ^[7].

Jak działa

Obsługa żądania, które coś zmienia, składa się z kilku niezależnych kontroli. Każda odpowiada na inne pytanie i żadna nie zastępuje pozostałych. Schemat poniżej pokazuje ich kolejność w typowej akcji wtyczki.

RYS. 1Kontrole przed wykonaniem akcji

Uwierzytelnianie ustala tożsamość, a weryfikacja uprawnień decyduje, co ta tożsamość może zrobić. OWASP opisuje kontrolę dostępu jako mechanizm, który sprawia, że użytkownicy nie mogą działać poza swoimi uprawnieniami ^[6].

Uprawnienia sprawdza się zawsze na serwerze. Ukrycie przycisku w interfejsie nie jest kontrolą: napastnik może wysłać to samo żądanie ręcznie. CWE-862 wśród zaleceń wymienia wymuszanie kontroli dostępu po stronie serwera na każdej stronie ^[7].

W WordPressie

WordPress łączy uprawnienia z rolami. Każdy zalogowany użytkownik dostaje zestaw uprawnień wynikający z jego roli, a wyższe role dziedziczą uprawnienia niższych ^[2]; zob. role i uprawnienia użytkowników. Dokumentacja dla autorów wtyczek wymaga, by kod uruchamiał się tylko wtedy, gdy bieżący użytkownik ma potrzebne uprawnienia ^[2].

Funkcja current_user_can() przyjmuje nazwę uprawnienia i opcjonalnie identyfikator obiektu. Dla uprawnień meta, takich jak edit_post, WordPress sprawdza prawo do konkretnego wpisu ^[1]. Dokumentacja odradza sprawdzanie nazw ról zamiast uprawnień, bo może dawać niepewne wyniki ^[1].

if ( ! current_user_can( 'edit_post', $post_id ) ) {
    wp_die( 'Brak uprawnień' );
}

Najczęstsze błędy w kodzie wtyczek wynikają z mylenia tej funkcji z innymi mechanizmami:

Nonce to nie uprawnienie. Dokumentacja WordPressa stwierdza, że na nonce'ach nie wolno polegać przy uwierzytelnianiu, autoryzacji ani kontroli dostępu ^[3]. Zaleca chronić funkcje przez current_user_can() i zawsze zakładać, że nonce może wpaść w niepowołane ręce ^[3]. Nonce chroni przed CSRF (Cross-Site Request Forgery), ale nie mówi nic o tym, kim jest użytkownik.

is_admin() to nie administrator. Funkcja is_admin() sprawdza, czy żądanie dotyczy panelu, a nie czy użytkownik jest administratorem; dokumentacja odsyła w tej sprawie do current_user_can() ^[5]. Notatka w dokumentacji zwraca uwagę, że is_admin() zwraca prawdę także dla żądań AJAX, bo plik wp-admin/admin-ajax.php ustawia stałą WP_ADMIN ^[5]. Kod, który w akcji AJAX uznaje is_admin() za dowód uprawnień, przepuszcza więc żądania każdego, kto dotrze do tego pliku. Przy akcjach dostępnych także dla niezalogowanych prowadzi to do podatności wykorzystywanej bez uwierzytelnienia.

REST API. Każdy własny punkt końcowy musi mieć permission_callback, który uruchamia się przed właściwą obsługą żądania ^[4]. Od wersji 5.5 brak tego argumentu wywołuje komunikat ostrzegawczy; dla punktów publicznych dokumentacja zaleca jawne __return_true ^[4]. Punkt końcowy bez sprawdzenia to niezabezpieczony endpoint REST API.

Zagrożenia i skutki

Brak weryfikacji uprawnień należy do kategorii Broken Access Control, którą OWASP umieścił na pierwszym miejscu listy OWASP Top 10 z 2021 roku ^[6]. Według OWASP 94% testowanych aplikacji sprawdzono pod kątem jakiejś formy tego błędu, a kategoria miała ponad 318 tysięcy wystąpień w zebranych danych, najwięcej ze wszystkich ^[6]. MITRE podaje, że CWE-862 znalazło się w zestawieniu CWE Top 25 za 2024 rok ^[7].

Skutki według MITRE obejmują odczyt i modyfikację danych wrażliwych, uzyskanie wyższych uprawnień oraz nadmierne zużycie zasobów prowadzące do odmowy usługi ^[7]. W WordPressie typowy scenariusz to podatność we wtyczce, w której użytkownik z rolą subskrybenta wywołuje akcję przeznaczoną dla administratora. Prowadzi to do eskalacji uprawnień, zmiany ustawień strony albo utworzenia nowego konta administratora. Pokrewny błąd to IDOR (Insecure Direct Object Reference), gdzie sprawdzenie dotyczy rodzaju operacji, ale nie konkretnego obiektu.

Jak się bronić

OWASP zaleca domyślne odmawianie dostępu z wyjątkiem zasobów publicznych, jeden centralny mechanizm kontroli dostępu w całej aplikacji, sprawdzanie własności rekordów oraz logowanie nieudanych prób i alarmowanie o nich ^[6]. Zaleca też testy funkcjonalne kontroli dostępu ^[6]. MITRE wymienia kontrolę dostępu opartą na rolach, czyli RBAC, i kontrole związane z logiką biznesową, a nie tylko z rodzajem zasobu ^[7].

W kodzie WordPressa oznacza to kilka reguł:

• każda akcja AJAX, każdy formularz w panelu i każdy punkt końcowy REST sprawdza current_user_can() z najwęższym potrzebnym uprawnieniem;
• przy operacjach na obiekcie przekazuje się jego identyfikator, np. edit_post z numerem wpisu ^[1];
• nonce i weryfikacja uprawnień występują razem, bo chronią przed różnymi atakami ^[3];
• nadawanie ról zgodnie z zasadą najmniejszych uprawnień.

Brak kontroli dostępu ma w słowniku osobne hasło: brak kontroli uprawnień (missing authorization).

Historia i przykłady

Błąd dotyczy także oprogramowania spoza WordPressa. CERT Polska 19 maja 2026 roku opublikował informację o podatnościach w produktach firmy Sparx Systems ^[8]. W CVE-2026-42096 z powodu braku weryfikacji uprawnień każdy uwierzytelniony użytkownik Sparx Pro Cloud Server mógł wykonywać dowolne zapytania SQL w kontekście użytkownika bazy danych ^[8]. Problem usunięto w Pro Cloud Server 6.2 ^[8].