Co ujawnia publiczne API WordPressa: kontrola tras REST i dostępu do danych

Management Summary
WordPress udostępnia katalog połączeń, przez które programy wymieniają dane z witryną. Pomaga to narzędziom redakcyjnym, rozszerzeniom i innym aplikacjom znaleźć dostępne funkcje. Wpis w katalogu nie oznacza jednak uprawnienia do odczytu prywatnych informacji lub zmiany strony. Artykuł wyjaśnia, co ujawnia taki spis i dlaczego nazwy, liczby albo udana odpowiedź nie dowodzą problemu z bezpieczeństwem. Ważne jest to, jakie dane i działania są faktycznie dostępne dla konkretnego odbiorcy.
Spis treści
Indeks REST WordPressa opisuje publicznie widoczne trasy API. Trasa jest ścieżką adresową, a punkt końcowy łączy ścieżkę z metodą HTTP i obsługą żądania. Sam wpis w indeksie nie oznacza zatem anonimowego dostępu do wszystkich powiązanych danych ani operacji zapisu.

Odnalezienie indeksu
Punkt wejścia często znajduje się pod /wp-json/. Lepszą informacją początkową jest publikowany przez WordPress odnośnik z relacją https://api.w.org/, na przykład w nagłówku HTTP lub HTML. Podkatalogi, zmienione prefiksy i systemy pośredniczące mogą wpływać na faktyczny URL API.
WordPress obsługuje także ?rest_route=/, również przy włączonych przyjaznych odnośnikach. Blokada pojedynczej ścieżki URL nie dowodzi więc pełnego ograniczenia dostępu. Z kolei odpowiedź 404 pod odgadniętą ścieżką nie dowodzi ani wyłączenia API, ani nawet działania witryny na WordPressie.
Liczba tras nie jest inwentarzem wtyczek
Przestrzeń nazw, na przykład vendor/v1, grupuje trasy. Numer wersji zwykle oznacza wersję API, a nie wydanie zainstalowanej wtyczki. Rozszerzenia mogą rejestrować kilka przestrzeni nazw, uzupełniać istniejące przestrzenie lub działać bez tras REST. Trasy mogą też pochodzić z motywów i własnego kodu. Publicznie widoczne dane indeksu podlegają dodatkowo filtrom.
Liczba opisuje więc wpisy w konkretnej odpowiedzi indeksu. Nie jest ani pełną listą zainstalowanych wtyczek, ani miarą podatności. Podobne liczby również nie dowodzą wspólnej platformy. Pełny inwentarz rozszerzeń wymaga danych administracyjnych.
Zadeklarowana metoda, na przykład POST lub DELETE, dokumentuje interfejs. Anonimowa próbka GET nie sprawdza uprawnień do zapisu. Znaczenie mają konkretna kontrola uprawnień i dane zwrócone w określonych warunkach żądania.
Status i treść wymagają wspólnej oceny
- 200: Żądanie zakończyło się sukcesem na poziomie HTTP. Dopiero typ treści, pełny poprawny JSON i oczekiwana struktura pozwalają rozpoznać właściwą odpowiedź REST. Strona blokady HTML ze statusem 200 nie jest listą użytkowników.
- 401 lub 403: Konkretne żądanie zostało odrzucone. Błąd WordPressa, zapora i usługa pośrednicząca są różnymi przyczynami. Status nie potwierdza poprawności uprawnień w całym API.
- 404: Pod adresem nie zwrócono pasującego zasobu. Możliwe pozostają błędna ścieżka, usunięta trasa lub reguły systemu pośredniczącego.
- Błąd pobrania lub ucięty JSON: Liczba nie została wiarygodnie ustalona. Wyświetlone zero nie stanowi dowodu braku tras.
Publiczni autorzy to nie wszystkie konta użytkowników
Domyślna trasa /wp/v2/users może zwracać publiczne dane autorów bez logowania. Bez uprawnienia list_users rdzeń ogranicza zwykłą listę do kont z opublikowanymi wpisami w typach treści widocznych w REST. Filtry i rozszerzenia mogą zmienić zachowanie. Listy są także dzielone na strony wyników: pojedyncza odpowiedź nie jest automatycznie pełnym zbiorem.
Publiczne pole slug odpowiada identyfikatorowi user_nicename przeznaczonemu do adresów URL. Wartość może różnić się od nazwy logowania. Osobne pole username należy w domyślnym schemacie do chronionego kontekstu edycji; hasła nigdy nie są zwracane. Publiczne nazwy autorów nie są więc ujawnionym plikiem haseł i same w sobie nie dowodzą podatności.
Publiczne identyfikatory mogą jednak ułatwiać niepożądany kontakt lub ukierunkowane próby logowania. Ocena zależy od faktycznie zwracanych danych i zamierzonego zakresu publiczności. Ochrona dostępu nadal wymaga skutecznego uwierzytelniania i właściwych uprawnień. Ukrycie pojedynczej listy nie zastępuje tych mechanizmów.
Precyzyjny opis uprawnień
WordPress sprawdza konkretne uprawnienia, a nie wyłącznie nazwy ról. Domyślna trasa ustawień sprawdza na przykład manage_options, a lista wtyczek activate_plugins. Wymagania dotyczące motywów zależą również od żądania. Ogólne stwierdzenie, że wszystkie te trasy wymagają uprawnień administratora, jest więc nieprecyzyjne.
Przy uwierzytelnianiu za pomocą ciasteczek nonce REST jest dodatkową wartością kontrolną przesyłaną z żądaniem. Pomaga chronić przed określonymi żądaniami, które obca witryna wywołuje przez przeglądarkę z aktywnym logowaniem. Nonce nie zastępuje ani logowania, ani kontroli uprawnień. Inne obsługiwane metody, na przykład hasła aplikacji przez HTTPS, nie korzystają z tej samej kombinacji ciasteczka i nonce. Nie każde prawidłowe żądanie REST wymaga nonce.
Ograniczenia narzędzia do inwentaryzacji tras
Podlinkowane narzędzie sprawdza /wp-json/ oraz, przy określonych błędach, ?rest_route=/. Następnie wykonuje dziesięć stałych prób GET. Nie jest to pełne wyszukiwanie adresów API ani test wszystkich metod.
Obecna ocena klasyfikuje próbki wyłącznie według statusu HTTP. Lokalny test ze sztuczną stroną blokady HTML i statusem 200 daje więc etykietę otwartej trasy. Pusta lista JSON otrzymuje tę samą etykietę. W tej implementacji oznaczenie nie dowodzi ujawnienia kont użytkowników.
Limit pobrania wynosi 8 MiB. Ucięty indeks powoduje wyświetlenie ostrzeżenia, ale liczba tras w obecnym wyniku nadal wynosi zero. Do oceny próbki trafia tylko pierwsze 4096 bajtów treści, przez co większa poprawna odpowiedź JSON może stać się nieczytelna. Nie ma pełnego zliczania użytkowników ani stronicowania. Grupowanie przestrzeni nazw wykorzystuje ponadto tylko pierwsze dwa segmenty ścieżki, co może błędnie łączyć dłuższe przestrzenie.
Sześć lokalnych przypadków testowych sprawdza te ograniczenia na sztucznych odpowiedziach. Wyniki nie tworzą nowego rankingu cudzych instalacji ani oceny bezpieczeństwa tych witryn.
Powiązany artykuł omawia publiczne dane w API REST WordPressa.
Pytania i odpowiedzi
Czy wyłączenie trasy użytkowników ukrywa publicznych autorów?
Nie. Archiwa autorów, odnośniki i mapy witryn mogą nadal zawierać publiczne identyfikatory. Ograniczenie musi odpowiadać zamierzonemu modelowi dostępu. Całkowite usunięcie trasy może też zakłócić funkcje edytora blokowego lub innych aplikacji.
Czy indeks może pozostać publiczny przy chronionych danych?
Tak. Opis interfejsu i dostęp do danych są osobnymi warstwami. Indeks ułatwia integrację, a uprawnienie jest sprawdzane dla konkretnej operacji.
Co stanowi wiarygodny dowód kontroli?
Faktyczny punkt wejścia API, czas, metoda, parametry, stan uwierzytelnienia, status i sprawdzona treść odpowiedzi wymagają wspólnego zapisu. Wnioski o ochronie zapisu wymagają odpowiednich autoryzowanych testów lub ukierunkowanej analizy kodu. Jedna anonimowa odpowiedź GET nie wystarcza.
Źródła
- WordPress: odnajdywanie API
- WordPress: własne punkty końcowe i przestrzenie nazw
- WordPress: metody uwierzytelniania
- WordPress: schemat użytkownika
- WordPress: publiczne listy użytkowników
- WordPress: uprawnienia motywów
- WordPress: uprawnienia wtyczek
- WordPress: uprawnienia ustawień
- WordPress: ograniczenia nonce
- WordPress: podział na strony wyników
- WordPress: filtry publicznego indeksu
- WordPress: podręcznik API REST
- WordPress: dokumentacja programistyczna


