autoryzacja

Autoryzacja to rozstrzygnięcie, czy żądana czynność lub usługa jest dozwolona dla konkretnego podmiotu ^[1]. OWASP, powołując się na NIST, podkreśla, że jest to coś innego niż uwierzytelnianie, czyli potwierdzenie tożsamości ^[1]. Uwierzytelnianie odpowiada na pytanie „kim jesteś”, autoryzacja na pytanie „co ci wolno”. MITRE zaznacza, że skrót „Auth” bywa mylący, dlatego w literaturze rozróżnia się AuthN (uwierzytelnianie) i AuthZ (autoryzacja) ^[3].

Jak działa

Autoryzacja następuje po uwierzytelnieniu. System zna już użytkownika i sprawdza, czy ma on prawo do danej operacji na danym zasobie. Decyzja zależy od trzech elementów: kto pyta, o jaki zasób i jaką czynność. Wynikiem jest zgoda albo odmowa.

OWASP wymaga, by aplikacja zawsze podejmowała decyzję, jawnie albo domyślnie, czy dostęp przyznać, czy go odmówić ^[1]. Zasada „domyślnie odmawiaj” (deny by default) oznacza, że brak reguły kończy się odmową, a nie zgodą ^[1]. Druga zasada mówi, że uprawnienia trzeba sprawdzać przy każdym żądaniu, niezależnie od tego, czy wysłał je skrypt AJAX, serwer, czy inne źródło ^[1]. Trzecią jest zasada najmniejszych uprawnień: użytkownik dostaje tylko minimum uprawnień potrzebnych do pracy ^[1].

Przebieg pojedynczej decyzji pokazuje schemat poniżej.

RYS. 1Kontrola dostępu przy jednym żądaniu

Modele kontroli dostępu

OWASP opisuje kilka modeli, według których system przyznaje uprawnienia ^[1]. Różnią się tym, na czym opiera się decyzja.

W praktyce modele się łączą. Rola daje ogólne prawo, a relacja z zasobem je zawęża, na przykład prawo edycji tylko własnych wpisów. Szersze ramy tych mechanizmów obejmuje zarządzanie tożsamością i dostępem.

W WordPressie

WordPress stosuje model oparty na rolach i uprawnieniach (capabilities). Ma sześć predefiniowanych ról: superadministrator, administrator, redaktor, autor, współpracownik i subskrybent ^[6]. Każda rola ma zestaw uprawnień, na przykład publish_posts, moderate_comments czy edit_users; uprawnienia można dodawać i odbierać funkcjami add_cap() i remove_cap() ^[6]. Subskrybent ma tylko uprawnienie read ^[6]. Dokumentacja zaleca, by nie traktować jednej roli jako starszej od innej, lecz jako opis obowiązków w witrynie ^[6]. Szerzej opisuje to hasło role i uprawnienia użytkowników.

Za autoryzację w kodzie odpowiada przede wszystkim funkcja current_user_can(). Podręcznik wtyczek formułuje zasadę wprost: kod wtyczki ma się wykonywać tylko wtedy, gdy bieżący użytkownik ma wymagane uprawnienia ^[5]. Ten sam podręcznik pokazuje błędny przykład, w którym brak sprawdzenia pozwala dowolnemu odwiedzającemu przenosić wpisy do kosza ^[5]. Poprawiona wersja otacza operację warunkiem:

if ( current_user_can( 'edit_others_posts' ) ) {
    wp_trash_post( $post_id );
}

Osobnym miejscem autoryzacji jest REST API. Od wersji 5.5 WordPress zgłasza ostrzeżenie _doing_it_wrong, gdy trasa nie ma argumentu permission_callback ^[7]. Dla tras publicznych dokumentacja zaleca jawne __return_true, a dla pozostałych funkcję sprawdzającą uprawnienia, na przykład current_user_can( 'edit_others_posts' ) ^[7]. Pominięcie tej kontroli prowadzi do niezabezpieczonego endpointu REST API.

Warto pamiętać, że nonce w WordPressie chroni przed CSRF (Cross-Site Request Forgery), ale nie zastępuje sprawdzenia uprawnień. Nonce potwierdza zamiar użytkownika, a current_user_can() jego prawo do czynności. Opisuje to hasło weryfikacja uprawnień.

Zagrożenia i skutki

MITRE opisuje dwie pokrewne słabości. CWE-285 to niewykonanie lub błędne wykonanie kontroli autoryzacji, gdy podmiot próbuje sięgnąć po zasób albo wykonać czynność ^[2]. CWE-862 to jej całkowity brak i jest węższym przypadkiem CWE-285 ^[3]. W słowniku odpowiada mu hasło brak kontroli uprawnień (missing authorization).

Skutki według MITRE obejmują trzy obszary ^[2]:

• poufność: odczyt wrażliwych danych z niedostatecznie chronionego magazynu albo przez uprzywilejowaną funkcję;
• integralność: modyfikację tych danych tą samą drogą;
• kontrolę dostępu: uzyskanie uprawnień i wykonanie nieautoryzowanego kodu lub poleceń, gdy kontrole są stosowane niekonsekwentnie.

Błędy autoryzacji tworzą kategorię Broken Access Control. W zestawieniu OWASP Top 10 z 2025 roku zajmuje ona pierwsze miejsce, a OWASP podaje, że jakąś formę tej słabości znaleziono w 100 procentach testowanych aplikacji ^[4]. Kategoria obejmuje 40 powiązanych CWE i 32 654 CVE ^[4]. Typowe konsekwencje to eskalacja uprawnień i IDOR (Insecure Direct Object Reference), czyli dostęp do cudzych rekordów przez podmianę identyfikatora.

Jak się bronić

OWASP w kategorii A01:2025 zaleca między innymi ^[4]:

• odmawiać dostępu domyślnie, z wyjątkiem zasobów publicznych;
• zbudować jeden mechanizm kontroli dostępu i używać go w całej aplikacji;
• egzekwować własność rekordów zamiast dawać dostęp do dowolnych danych;
• unieważniać identyfikatory sesji po stronie serwera po wylogowaniu;
• dodać testy funkcjonalne kontroli dostępu do testów jednostkowych i integracyjnych.

MITRE dodaje, by kontrole wykonywać po stronie serwera i korzystać ze sprawdzonych mechanizmów, takich jak RBAC ^[2]. Sprawdzenie w przeglądarce, na przykład ukrycie przycisku, nie jest autoryzacją, bo atakujący może wysłać żądanie bezpośrednio.

W WordPressie oznacza to w praktyce: current_user_can() przed każdą operacją zmieniającą dane, permission_callback przy każdej trasie REST oraz przegląd, kto ma rolę administratora. Nieznane konto z najwyższą rolą może oznaczać nieautoryzowane konto administratora.

Historia i przykłady

Brak autoryzacji na trasie REST jest jednym z przykładów, które MITRE podaje przy CWE-285. Chodzi o CVE-2024-6845: wtyczka WordPressa z czatbotem nie sprawdzała autoryzacji na punkcie końcowym REST, co pozwalało pobrać klucz API ^[2]. Przypadek ilustruje typowy schemat: podatność we wtyczce polega nie na złamaniu zabezpieczeń, lecz na tym, że kontrola w ogóle nie istnieje. OWASP odnotowuje, że Broken Access Control uznano za najpoważniejszą podatność aplikacji webowych już w zestawieniu Top 10 z 2021 roku ^[1].