niezabezpieczony endpoint REST API

Niezabezpieczony endpoint REST API (REST API abuse) to punkt końcowy interfejsu REST, który wykonuje akcję albo zwraca dane bez sprawdzenia, kto pyta i czy mu wolno. W WordPressie typową przyczyną jest trasa zarejestrowana przez wtyczkę bez właściwej funkcji permission_callback, która według dokumentacji sprawdza, czy użytkownik może wykonać daną akcję, zanim zostanie wywołana właściwa obsługa żądania ^[1]. MITRE opisuje ogólną postać tego błędu jako CWE-862: produkt nie wykonuje kontroli autoryzacji, gdy ktoś próbuje uzyskać dostęp do zasobu albo wykonać akcję ^[5].

Jak działa

REST API WordPressa udostępnia trasy pod adresem z przedrostkiem wp-json, na przykład example.com/wp-json/myplugin/v1/author/1 ^[1]. Trasa to adres URL, a endpoint to funkcja przypisana do metody HTTP i tego adresu ^[1]. Wtyczki i motywy rejestrują własne trasy funkcją register_rest_route w akcji rest_api_init ^[1].

Każdy endpoint ma dwie funkcje: callback, która wykonuje pracę, i permission_callback, która decyduje, czy żądanie w ogóle przejdzie dalej. Jeśli permission_callback zwróci true, żądanie jest przetwarzane; jeśli false, API zwraca domyślny komunikat o błędzie i nie idzie dalej ^[1]. Dla tras publicznych dokumentacja wskazuje wbudowaną funkcję __return_true ^[1]. Właśnie tu powstaje błąd: autor wtyczki oznacza jako publiczną trasę, która zwraca dane poufne albo zmienia ustawienia.

Poniżej schemat żądania do trasy, która nie sprawdza uprawnień.

RYS. 1Żądanie do niezabezpieczonej trasy

OWASP opisuje tę samą klasę w interfejsach API jako API5:2023 Broken Function Level Authorization. Wykorzystanie polega na wysłaniu poprawnych wywołań API do endpointu, do którego atakujący jako anonim albo zwykły użytkownik nie powinien mieć dostępu ^[4]. Według OWASP wystawione endpointy są łatwe do wykorzystania ^[4].

W WordPressie

Od wersji 5.5 WordPress zgłasza komunikat _doing_it_wrong, gdy trasa nie ma permission_callback ^[1]. Komunikat pomaga wychwycić brak funkcji, ale nie ocenia jej treści. Trasa z __return_true przechodzi bez ostrzeżenia, nawet gdy zwraca dane, które powinien widzieć tylko administrator.

Poprawny wzorzec z dokumentacji sprawdza uprawnienie funkcją current_user_can, na przykład edit_others_posts ^[1]. Sprawdzenie opiera się na rolach i uprawnieniach użytkowników.

register_rest_route( 'myplugin/v1', '/settings', array(
  'methods'             => 'GET',
  'callback'            => 'myplugin_get_settings',
  'permission_callback' => function () {
    return current_user_can( 'manage_options' );
  },
) );

Ważne jest też, jak API rozpoznaje użytkownika. Wtyczki i motywy korzystają z uwierzytelniania ciasteczkami, a REST API stosuje nonce z akcją wp_rest, by uniknąć ataków CSRF (Cross-Site Request Forgery) ^[2]. Bez nonce API ustawia bieżącego użytkownika na 0, więc żądanie staje się nieuwierzytelnione, nawet gdy ktoś jest zalogowany ^[2]. Integracje zewnętrzne mogą od wersji 5.6 używać haseł aplikacji, przesyłanych przez HTTPS w schemacie Basic ^[2].

Zagrożenia i skutki

Skutek zależy od tego, co robi callback. Endpoint może ujawnić dane konfiguracyjne, w tym dane uwierzytelniające do usług zewnętrznych, może też zmieniać ustawienia albo tworzyć treści. Taki błąd to zwykle podatność wykorzystywana bez uwierzytelnienia, bo wystarczy znajomość adresu. Mieści się w szerszej kategorii Broken Access Control i jest odmianą braku kontroli uprawnień. Gdy endpoint zwraca dane osobowe, może dojść do wycieku danych.

Na liście przykładów OWASP opisuje endpoint przeznaczony tylko dla administratorów, który zwraca dane wszystkich użytkowników i nie ma kontroli uprawnień; atakujący zgaduje jego adres i odczytuje dane ^[4].

Jak się bronić

• Autorzy wtyczek. OWASP zaleca spójny moduł autoryzacji wywoływany ze wszystkich funkcji oraz domyślną odmowę dostępu z jawnymi uprawnieniami dla ról ^[4]. W WordPressie oznacza to weryfikację uprawnień w każdej permission_callback i __return_true tylko dla danych jawnych.
• Administratorzy. Dokumentacja odradza wyłączanie REST API, bo zepsuje to funkcje panelu, które z niego korzystają ^[3]. Zamiast tego można filtrem rest_authentication_errors wymagać uwierzytelnienia dla wszystkich żądań, co w praktyce blokuje anonimowy dostęp z zewnątrz ^[3].
• Aktualizacje i obserwacja. Błąd siedzi w kodzie wtyczki, więc usuwa go dopiero łatka (patch). Do tego czasu ruch do konkretnej trasy może zatrzymać WAF albo wirtualne patchowanie (virtual patching). Logi dostępu pozwalają sprawdzić, czy ktoś już pytał o podatną ścieżkę ^[6].

Historia i przykłady

Gravity SMTP (CVE-2026-4020). Sekurak opisał podatność we wtyczce Gravity SMTP polegającą na braku uwierzytelnienia dla jednego z endpointów REST API ^[6]. Pojedyncze żądanie GET do trasy gravitysmtp/v1/tests/mock-data zwracało pełny raport systemowy z aktywną konfiguracją SMTP ^[6]. Administrator, którego przypadek opisano, obsługiwał 185 witryn; poświadczenia do usługi Mailgun ujawniło 86 z nich ^[6]. Skanowanie prowadzono z 806 unikalnych adresów IP przez co najmniej 36 dni ^[6]. Błąd poprawiono w wersji 2.1.5; Sekurak radził przeszukać logi pod kątem żądań do tej trasy, bo odpowiedź 200 może oznaczać ujawnienie poświadczeń ^[6]. Po takim zdarzeniu ujawnione klucze trzeba wymienić; zob. rotacja kluczy.

HyperView Geoportal Toolkit (CVE-2024-6449). Problem nie dotyczy tylko WordPressa. CERT Polska 28 sierpnia 2024 roku opisał podatność polegającą na wykorzystaniu jednego z endpointów REST API do odwoływania się do niezaufanych zewnętrznych domen ^[7]. Podatne były wersje poniżej 8.5.0 ^[7].