hasła aplikacji

Hasła aplikacji (Application Passwords) to mechanizm WordPressa, w którym dla każdej zewnętrznej aplikacji generuje się osobne hasło, używane zamiast głównego hasła konta przy połączeniach z API. Funkcja jest w rdzeniu od wersji 5.6, a hasła tworzy się na stronie edycji użytkownika w panelu ^[1]. Działają z REST API i z XML-RPC ^[2]. Każde hasło można odwołać osobno, ale każde daje aplikacji te same uprawnienia, które ma użytkownik ^[2].

Jak działa

Hasło aplikacji służy do uwierzytelniania programu, a nie człowieka. Dokumentacja podkreśla, że nie da się nim zalogować przez wp-login.php, bo jest przeznaczone do użycia programowego, a nie do sesji interaktywnych ^[2]. W REST API aplikacja wysyła nazwę użytkownika i hasło w schemacie Basic Auth opisanym w RFC 7617 ^[1]. Dokumentacja pokazuje to na przykładzie narzędzia curl, które wysyła parę użytkownik i hasło do punktu końcowego wp/v2/users ^[1]. W XML-RPC hasło aplikacji podaje się w miejscu zwykłego hasła konta ^[2].

Hasło ma 24 znaki, same litery i cyfry, co według twórców daje ponad 142 bity entropii ^[2]. Panel pokazuje je w grupach po cztery znaki, ale spacje można pominąć ^[2]. W bazie WordPress przechowuje tylko skrót hasła w metadanych użytkownika, więc pełną wartość widać wyłącznie raz, przy tworzeniu ^[2]. Obok każdego hasła zapisywana jest data utworzenia, data ostatniego użycia z dokładnością do 24 godzin i ostatni adres IP ^[2].

Aplikacja może też poprosić o hasło sama. Kieruje wtedy użytkownika na stronę /wp-admin/authorize-application.php z nazwą aplikacji i adresem powrotu success_url ^[2]. Przebieg pokazuje schemat poniżej.

RYS. 1Nadanie hasła aplikacji i pierwsze żądanie

Po zatwierdzeniu WordPress dopisuje do adresu success_url trzy parametry: site_url, user_login i password ^[2]. Parametr app_id pozwala twórcy aplikacji rozpoznawać hasła wydane jej instalacjom, na przykład po to, by odwołać hasła skompromitowanej wersji programu ^[2]. Adres powrotu z protokołem http:// powoduje błąd; dozwolone są https:// i własne protokoły aplikacji ^[2].

Porównanie z innymi metodami

Uwierzytelnianie ciasteczkiem działa tylko dla kodu uruchomionego wewnątrz WordPressa, gdy użytkownik jest zalogowany; bez nonce z akcją wp_rest żądanie jest traktowane jak anonimowe ^[1]. Hasła aplikacji wypełniają lukę dla programów spoza przeglądarki: aplikacji mobilnych, integracji z systemami sklepu, skryptów publikujących treść.

W WordPressie

Domyślnie funkcja wymaga HTTPS ^[2]. Dokumentacja REST API mówi, że dane logowania można przekazywać w żądaniach obsługiwanych przez https:// ^[1]. Wymóg ma uzasadnienie w samym schemacie Basic: RFC 7617 stwierdza, że hasło jest w nim przesyłane otwartym tekstem, a kodowanie Base64 niczego nie szyfruje, więc schematu nie należy używać bez takich zabezpieczeń jak HTTPS ^[4]. Twórcy WordPressa ostrzegają, że bez SSL hasło aplikacji może zobaczyć atakujący w tej samej sieci ^[2].

Dostępność funkcji kontroluje filtr wp_is_application_passwords_available, wprowadzony w wersji 5.6.0 ^[3]. Wyłączenie wygląda tak:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Drugi filtr, wp_is_application_passwords_available_for_user, pozwala ograniczyć funkcję do wybranych użytkowników, na przykład według ról ^[2]. Rdzeń nie ma zakresów uprawnień dla pojedynczego hasła: aplikacja dostaje wszystko, co wolno użytkownikowi ^[2]. Dlatego znaczenie mają role i uprawnienia użytkowników konta, dla którego hasło powstaje.

Osobną kwestią jest drugi składnik logowania. Wtyczka Two Factor z katalogu WordPress.org od wersji 0.14.0 domyślnie dopuszcza hasła aplikacji do uwierzytelniania w REST API i XML-RPC, a zwykłe hasło konta w XML-RPC pozostaje zablokowane ^[5]. Żądanie z hasłem aplikacji nie przechodzi przez ekran z kodem jednorazowym, więc uwierzytelnianie dwuskładnikowe nie chroni tej drogi dostępu.

Zagrożenia i skutki

Hasło aplikacji jest pełnoprawnym poświadczeniem. Kto je zdobędzie, działa w API z uprawnieniami użytkownika, bez znajomości głównego hasła i bez drugiego składnika.

• Wyciek z integracji. Hasło zapisane w konfiguracji innego systemu albo zaszyte w kodzie może wyciec razem z tym systemem.
• Podsłuch. Bez HTTPS hasło da się przechwycić w sieci ^[2], na przykład w ataku man-in-the-middle (MITM).
• Pozostawiony dostęp po włamaniu. Każde hasło aplikacji jest osobnym poświadczeniem, odwoływanym niezależnie od innych ^[2]. Hasło dodane przez intruza do konta administratora trzeba więc odwołać osobno; pominięte może działać jak tylna furtka.
• Nadmiar uprawnień. Integracja, która potrzebuje tylko publikacji wpisów, dostaje hasło administratora i z nim pełny panel.

Dobre praktyki

• Tworzyć osobne konto dla każdej integracji, z najniższą rolą, która wystarcza do jej zadania, zgodnie z zasadą najmniejszych uprawnień.
• Jedno hasło na jedną aplikację i opisowa nazwa, żeby dało się je odwołać bez wpływu na inne integracje ^[2].
• Przeglądać listę haseł w profilach administratorów. Kolumny ostatniego użycia i ostatniego adresu IP ^[2] pomagają wykryć hasła nieużywane i nieznane.
• Przechowywać hasła w menedżerze haseł albo w systemie zarządzania sekretami, nie w repozytorium kodu.
• Wyłączyć funkcję filtrem, jeśli strona nie ma żadnych integracji ^[3].
• Po przejęciu konta albo całej strony odwołać wszystkie hasła aplikacji. CERT Polska zaleca po włamaniu zmianę wszystkich haseł i kluczy, do których atakujący mógł mieć dostęp ^[6]; hasła aplikacji należą do tej grupy. Pełną procedurę opisuje hasło czyszczenie przejętej strony.