Podatności Grav API plugin

Wtyczka Grav API przed wersją 1.0.3 nie oczyszcza plików SVG przesyłanych przez endpoint POST /api/v1/media. Metoda processUploadedFile() sprawdza tylko rozszerzenie pliku, nie wywołując Security::sanitizeSVG(), co pozwala uwierzytelnionemu atakującemu z uprawnieniem api.media.write na przesłanie SVG z dowolnym kodem JavaScript. Plik jest przechowywany bez zmian i serwowany z Content-Type: image/svg+xml; gdy administrator otworzy go w przeglądarce, osadzony skrypt wykonuje się w kontekście jego sesji, umożliwiając kradzież ciasteczek i przejęcie sesji.

Wtyczka Grav API przed wersją 1.0.0-rc.16 akceptuje tokeny JWT w parametrze URL ?token= i odpowiada nagłówkiem Access-Control-Allow-Origin: *, co pozwala nieuwierzytelnionym atakującym na wykonywanie w pełni uwierzytelnionych żądań API z dowolnej złośliwej strony. Atakujący, którzy zdobędą wyciekły token JWT z logów dostępu, logów proxy, historii przeglądarki lub nagłówków Referrer, mogą utworzyć trwałe konta super-admina i wykraść wrażliwe dane konfiguracyjne oraz użytkowników.

Wtyczka Grav API to RESTful API dla Grav CMS, które umożliwia pełny dostęp do treści, mediów, konfiguracji i zarządzania użytkownikami. W wersjach przed 1.0.0-beta.15 występuje luka związana z niebezpiecznym bezpośrednim odniesieniem do obiektu oraz błędem logicznym, co pozwala uwierzytelnionym użytkownikom na modyfikację swoich uprawnień.

Podatność w Grav API Plugin (wtyczka do Grav CMS) przed wersją 1.0.6. WebhookController.php akceptuje adresy URL webhooków po tylko składniowej walidacji FILTER_VALIDATE_URL, a WebhookDispatcher.php inicjalizuje cURL bez ograniczeń CURLOPT_PROTOCOLS lub CURLOPT_REDIR_PROTOCOLS. Konto z uprawnieniami api.webhooks.write może wysyłać żądania do plików, dict, gopher, sieci prywatnych lub link-local, pobierać lokalne pliki i odpowiedzi, a także przekierowywać żądania do wewnętrznych usług lub endpointów metadanych chmury. Problem naprawiono w wersji 1.0.6.

Wtyczka Grav api (grav-plugin-api) przed wersją 1.0.8 nieprawidłowo autoryzuje generowanie i odwoływanie kluczy API. Przechwytuje zadania administracyjne apiKeyGenerate/apiKeyRevoke przed wykonaniem ACL zarządzania kontami i autoryzuje wywołującego tylko na podstawie uprawnienia admin.login (podstawowe uprawnienie posiadane przez każdego użytkownika panelu). Umożliwia to każdemu użytkownikowi z admin.login wygenerowanie trwałego klucza API powiązanego z dowolnym kontem, a sfałszowany klucz dziedziczy uprawnienia API konta docelowego. W instalacjach, gdzie konto z włączonym API ma szersze uprawnienia, umożliwia to podszywanie się pod konto i eskalację uprawnień aż do przejęcia konta.

Wtyczka Grav API (grav-plugin-api) przed wersją 1.0.4 nie weryfikuje pochodzenia pola admin_base_url w punkcie końcowym POST /api/v1/auth/forgot-password. Funkcja sanitizeHttpUrl() sprawdza tylko schemat URL (http/https), ale nie sprawdza hosta względem własnego serwera, co pozwala atakującemu na podstawienie dowolnego hosta. Nieuwierzytelniony atakujący może spowodować, że e-mail resetujący hasło wysłany do ofiary będzie zawierał link prowadzący do serwera kontrolowanego przez atakującego; gdy ofiara kliknie link, prawidłowy token resetujący zostaje ujawniony atakującemu, co umożliwia pełne przejęcie konta.

Wtyczka Grav API przed wersją 1.0.20 buduje linki do resetowania hasła z niezaufanego nagłówka Host w punkcie końcowym forgot-password, co pozwala nieuwierzytelnionym atakującym przekierować tokeny resetowania do domen kontrolowanych przez atakującego. Atakujący mogą wysyłać żądania resetowania hasła dla dowolnego konta ze złośliwym nagłówkiem Host, przechwycić token resetowania z wiadomości e-mail ofiary i przejąć konto, w tym konta super-admina.

Plugin Grav API (getgrav/grav-plugin-api) przed wersją 1.0.18 nie egzekwuje ograniczeń zakresu klucza API w funkcji injectSecurityTab() klasy BlueprintController. Osoba posiadająca klucz API z ograniczonym zakresem może zobaczyć i potencjalnie edytować pola uprawnień strony poza przyznanym zakresem.

Wtyczka Grav API przed wersją 1.0.16 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w dostarczaniu webhooków, która pozwala atakującym ominąć walidację nazwy hosta przez ponowne wiązanie DNS. Atakujący kontrolujący autorytatywny DNS dla skonfigurowanej nazwy hosta webhooka mogą odpowiadać na zapytania walidacyjne publicznymi adresami, a na zapytania dostarczania prywatnymi adresami, aby dotrzeć do wewnętrznych zasobów sieciowych.

Grav API Plugin przed wersją 1.0.8 przechwytuje zadania administracyjne apiKeyGenerate i apiKeyRevoke w user/plugins/api/api.php i autoryzuje wywołującego tylko przez admin.login. Podstawowy użytkownik panelu może wybrać inne konto z trasy, utworzyć trwałe poświadczenie ApiKeyManager powiązane z tym celem i odziedziczyć uprawnienia API celu, w tym api.super lub administracyjny zapis, jeśli są obecne. Problem został naprawiony w wersji 1.0.8.

Grav API Plugin przed wersją 1.0.0-rc.16 akceptuje JWT z parametru token w URL na każdej trasie /api/v1, w tym na punktach końcowych zmieniających stan. Żądania URL narażają ważne tokeny dostępu na logi Apache, proxy i CDN, historię przeglądarki i nagłówki Referer, co pozwala osobie z dostępem do tych rekordów na ponowne użycie tokena z uprawnieniami właściciela. Problem został naprawiony w wersji 1.0.0-rc.16.

Grav API Plugin przed wersją 1.0.0-rc.16 w CorsMiddleware zwraca Access-Control-Allow-Origin: * i permisywne odpowiedzi OPTIONS dla uwierzytelnionych punktów końcowych /api/v1. JavaScript z dowolnego pochodzenia może przesłać JWT uzyskany przez atakującego przez nagłówek Authorization lub X-API-Token, odczytać uwierzytelnioną odpowiedź i wykonać operacje zapisu z uprawnieniami właściciela tokena, umożliwiając eksfiltrację danych i modyfikację konta. Problem został naprawiony w wersji 1.0.0-rc.16.

Wtyczka Grav API przed wersją 1.0.6 zawiera podatność, w której ApiKeyManager::generateKey() przechowuje zadeklarowaną tablicę zakresów, ale ApiKeyAuthenticator::authenticate() nie odczytuje keyData[scopes] i zwraca pełną tożsamość właściciela klucza. W rezultacie AbstractApiController::requirePermission() ocenia pełne ACL użytkownika, więc klucz wydany dla zakresu tylko do odczytu może wykonywać wszystkie operacje zapisu, usuwania i administracyjne dostępne właścicielowi. Problem naprawiono w wersji 1.0.6.

Wtyczka Grav API przed wersją 1.0.6 zawiera podatność, w której metody UsersController::createApiKey(), generate2fa() i disable2fa() pomijają sprawdzenie celu accessGrantsSuper() używanego w innych endpointach mutacji użytkownika. Konto niebędące superadministratorem z uprawnieniem api.users.write może utworzyć klucz API powiązany z celem access.api.super, uzyskać pełne uprawnienia celu, ponieważ zakresy kluczy nie są egzekwowane, i stworzyć trwały dostęp superadministratora; brakujące sprawdzenie umożliwia również rotację lub wyłączenie uwierzytelniania dwuskładnikowego celu. Problem naprawiono w wersji 1.0.6.

Wtyczka Grav API przed wersją 1.0.2 w procesie POST /api/v1/media w HandlesMediaUploads::processUploadedFile() waliduje rozszerzenie pliku SVG, ale nie wywołuje Security::sanitizeSVG(). Atakujący z uprawnieniem api.media.write może przechowywać SVG zawierający JavaScript, a serwer zwraca plik jako Content-Type: image/svg+xml, co powoduje wykonanie skryptu po otwarciu przez ofiarę, umożliwiając kradzież danych sesji i autoryzowane działania.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do stosu admin-next/API Grav) przed wersją 1.0.14 nie egzekwuje wymogu autoryzacji w MenubarController::executeAction(). Podczas gdy punkt końcowy GET /menubar/items poprawnie filtruje elementy paska menu przez userPassesAuthorize(), punkt końcowy POST /api/v1/menubar/actions/{plugin}/{action} sprawdza tylko podstawowe uprawnienie api.access i nigdy nie ocenia pola authorize, które wtyczka zarejestrowała dla tej akcji. Każdy uwierzytelniony wywołujący z api.access może zatem bezpośrednio wywołać uprzywilejowaną akcję paska menu, omijając zamierzoną autoryzację. Żadna wtyczka dołączona do rdzenia Grav nie rejestruje obecnie uprzywilejowanego handlera authorize, więc na standardowej instalacji wpływ jest utajony; wada dotyczy każdej wtyczki pierwszej lub trzeciej strony polegającej na udokumentowanej semantyce authorize.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.14 zawiera podatność braku autoryzacji w funkcji userPassesAuthorize() (AbstractApiController.php). Funkcja nie sprawdza zakresów klucza API żądania, opierając się zamiast tego na surowym flagu super-admina i uprawnieniach ACL. W rezultacie uwierzytelniony atakujący posiadający klucz API z ograniczonym zakresem, wybity na koncie z uprawnieniami administratora, może ominąć deklarowane ograniczenia zakresu i uzyskać dostęp do metadanych UI i definicji elementów (sidebar/menubar/widget items oraz users-list columns/row-actions/filter-tabs), które powinny być dla niego zabronione, co prowadzi do ujawnienia informacji.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do Grav 2.0 w stosie admin-next/API) przed wersją 1.0.14 zawiera słabość otwartego przekierowania w SsoController::sanitizeReturnTo(). Funkcja odrzuca dosłowny prefiks '//', ale nie uwzględnia normalizacji backslashy do slashy przez przeglądarki w specjalnych schematach (http/https), więc wartość returnTo taka jak '/\evil.com' przechodzi przez zabezpieczenie i jest później rozwiązywana przez przeglądarkę jako URL względny protokołu '//evil.com'. Po legalnym przepływie logowania OAuth, parametr returnTo dostarczony przez atakującego może przekierować uwierzytelnioną ofiarę na stronę kontrolowaną przez atakującego w celu phishingu po zalogowaniu. Pełna eksploitowalność po stronie przeglądarki zależy od handlera oauth-callback po stronie klienta w admin-next SPA i nie została niezależnie zweryfikowana przez reportera.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do Grav 2.0) przed wersją 1.0.14 (naprawiona w 1.0.15) zawiera podatność braku autoryzacji w BlueprintPathResolver::resolveUserScope(). Metoda blokuje zakres users/<name> na surowym flagu super-admina ACL (access.api.super) zamiast weryfikować faktyczny zakres prezentowanego klucza API. Atakujący posiadający klucz API z zakresem tylko api.media.write, wybity na koncie super-admina, może ominąć kontrolę autoryzacji i, przez POST /blueprint-upload lub GET /blueprint-files, zapisać plik w zakresie innego użytkownika (w wspólnym katalogu user/accounts/, ograniczonym do rozszerzeń obrazów przez assertSafeExtension()) i przeglądać listę plików w tym zakresie, mimo że klucz nie ma uprawnień api.users.write.

Wtyczka Grav API (getgrav/grav-plugin-api) w wersjach od 1.0.6 do 1.0.11 zawiera podatność na eskalację uprawnień. Klucz API z ograniczonym zakresem wygenerowany na koncie super-admina omija zadeklarowany limit zakresu na czterech punktach końcowych zapisu chronionych funkcją isSuperAdmin() (w GroupsController, AccountsConfigController, PreferencesController i DashboardWidgetController). Te punkty końcowe autoryzują przez wczesny zwrot dla super-admina, który nigdy nie wywołuje requirePermission() – jedynego punktu egzekwowania limitu zakresu – więc klucz z zakresem 'read-only' (np. api.pages.read) może wykonywać operacje zapisu tylko dla super-admina, w tym przepisywanie map ACL grup w celu nadania uprawnień super-admina dowolnym kontom. Wyciekły lub delegowany klucz CI/monitorujący z zakresem read-only może zatem uzyskać pełną zdolność zapisu super-admina. Poprawiono w wersji 1.0.13.

Wtyczka Grav API przed wersją 1.0.13 nie egzekwuje ograniczeń zakresu kluczy API w bramkach super-scope w ConfigController, co pozwala kluczom z ograniczonym zakresem na zapis konfiguracji harmonogramu. Ograniczenie zakresu jest stosowane tylko wewnątrz requirePermission(), podczas gdy bramki harmonogramu i kopii zapasowych używają gołego sprawdzenia isSuperAdmin(), które nigdy nie konsultuje api_key_scopes. Atakujący posiadający klucz API z zakresem api.config.write, wygenerowany na koncie super, może wstrzyknąć dowolne polecenia do scheduler.custom_jobs, które Job::run() przekazuje do Symfony Process, osiągając wykonanie poleceń systemu operacyjnego jako użytkownik serwera WWW.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.13 zawiera obejście ograniczeń zakresu kluczy API w metodach create() i update() w UsersController. Metody te egzekwują ograniczenia tylko dla api.users.write, ale przyznają super-przywileje na podstawie bezpośredniego sprawdzenia isSuperAdmin(), które czyta access.api.super bez uwzględniania zakresów klucza. W rezultacie klucz o zakresie api.users.write wybity na koncie super może ustawić access.api.super lub przypisać grupę nadającą super, aby utworzyć lub awansować pełne konto super, a następnie uwierzytelnić się jako to konto dla nieograniczonych uprawnień administracyjnych.

Wtyczka getgrav/grav-plugin-api przed wersją 1.0.13 nie weryfikuje, czy zakresy nowo utworzonego klucza API są podzbiorem zakresów wywołującego w createApiKey. Ścieżka self-target w requireApiKeyPermission() wymaga tylko podstawowego zakresu api.access, a zakresy nowego klucza są odczytywane bezpośrednio z treści żądania bez sprawdzania podzbioru. Atakujący posiadający klucz API o minimalnym zakresie na koncie super może przesłać pustą tablicę zakresów, aby wybić nieograniczony klucz super z pełnym dostępem, omijając ograniczenia zakresów (i umożliwiając dalsze łańcuchy, takie jak zapis konfiguracji do RCE).

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.13 zawiera obejście ograniczeń zakresu kluczy API w PagesController::guardTwigContent(). Sprawdzanie przełącznika Twig używa bezpośredniego wywołania isSuperAdmin(), które nie uwzględnia api_key_scopes, więc klucz API o najmniejszych uprawnieniach, ograniczony tylko do api.pages.write i wybity na koncie super, może włączyć process.twig podczas zapisu strony, mimo że admin.pages_twig jest celowo poza zakresem api.pages. Gdy security.twig_content.process_enabled=true i editor_enabled=false, umożliwia to wykonanie Twig-in-content po stronie serwera, co prowadzi do wstrzyknięcia szablonów po stronie serwera (SSTI) i zdalnego wykonania kodu.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.13 zawiera obejście ograniczeń zakresu klucza API w DemoController. Prywatna metoda requireSuper() sprawdza isSuperAdmin() i zwraca wcześniej, przed wywołaniem requirePermission(), więc ograniczenie api_key_scopes (egzekwowane tylko w requirePermission()) jest pomijane. W rezultacie każdy klucz API z ograniczonym zakresem wybity na koncie super może ominąć ograniczenia zakresu podczas wywoływania operacji baseline() i reset() (np. POST /api/v1/demo/reset), umożliwiając przechwycenie baseline demo lub wymuszenie resetu demo. Wpływ jest ograniczony do kontroli silnika demo i jest warunkowy, jeśli tryb demo jest skonfigurowany z zasobami do zapisu.

Pakiet Composer getgrav/grav-plugin-api przed wersją 1.0.13 (dotknięte <= 1.0.12) nie egzekwuje ograniczeń zakresu kluczy API na punkcie końcowym disable2fa. W przeciwieństwie do pokrewnego punktu generate2fa, disable2fa autoryzuje ścieżkę admin (nie-self) wyłącznie przez odczyty ACL (isSuperAdmin/hasPermission) i nigdy nie wywołuje requirePermission(), więc ograniczenie api_key_scopes nie jest stosowane. W rezultacie posiadacz klucza API o wąskim zakresie na koncie super lub konto nie-super, którego ACL zawiera api.users.write, może wymusić wyłączenie dwuskładnikowego uwierzytelniania na dowolnym koncie nie-super przez POST /api/v1/users/{user}/2fa/disable bez podawania kodu TOTP, co ułatwia przejęcie konta.

Grav API Plugin przed wersją 1.0.10 nie waliduje pola groups w metodzie InvitationsController::create(), co pozwala uwierzytelnionym wywołującym z uprawnieniami api.users.write na przypisywanie zaproszonych kont do grup przyznających uprawnienia api.super. Atakujący mogą tworzyć rekordy zaproszeń z podwyższonym członkostwem w grupach, a po ich zaakceptowaniu nowe konto uzyskuje pełny dostęp API super-admina, mimo że zapraszający nie posiada tych uprawnień.

Grav API Plugin przed wersją 1.0.10 nieprawidłowo waliduje pole slug w endpointcie POST /pages/{route}/move. Metoda PagesController::move() oczyszcza slug tylko za pomocą ltrim($body['slug'], '.'), co usuwa początkowe kropki, ale nie neutralizuje segmentów '/' ani '..'. Uwierzytelniony wywołujący API z uprawnieniami api.pages.write może podać sekwencję path traversal (np. 01.home/../../../pwned), aby przenieść cały katalog strony (treść i multimedia) do dowolnej lokalizacji z możliwością zapisu poza user/pages/, w tym poza instalacją Grav.

Grav API Plugin przed wersją 1.0.10 nie ogranicza dostępu do zapisu do krytycznych dla bezpieczeństwa zakresów konfiguracji wtyczek, co pozwala uwierzytelnionym użytkownikom z uprawnieniami api.config.write na modyfikację ustawień rate limiting i CORS. Atakujący mogą wyłączyć rate limiting w całej witrynie, aby umożliwić ataki brute-force na hasła, oraz zmienić polityki CORS, aby obejmowały kontrolowane przez atakującego źródła z włączonymi poświadczeniami.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.0-rc.16 domyślnie ustawiała nagłówek Access-Control-Allow-Origin: * we wszystkich odpowiedziach, w tym w uwierzytelnionych punktach końcowych i odpowiedziach preflight (OPTIONS). Ponieważ wtyczka akceptuje poświadczenia przez nagłówki Authorization i X-API-Token (ustawiane programowo przez JavaScript, a nie przez ciasteczka), atakujący, który zdobędzie ważny token dostępu (np. przez wyciek logów, nagłówki Referer, historię przeglądarki lub przechwycenie sieci), może wysyłać w pełni uwierzytelnione żądania międzyoriginowe z dowolnej złośliwej strony, aby odczytać wrażliwe dane i wykonać operacje zapisu jako użytkownik tokena.

Podatność w Grav API plugin przed wersją 1.0.0-rc.16. Tokeny JWT są akceptowane przez parametr URL ?token=, co powoduje ich logowanie w logach serwera, wyciek przez nagłówek Referer, przechowywanie w historii przeglądarki i logach proxy/CDN. Wyciek tokena umożliwia nieautoryzowany dostęp API, w tym odczyt konfiguracji i danych użytkowników, tworzenie kont admina, modyfikację ustawień systemowych i usuwanie stron.

Wtyczka Grav API przed wersją 1.0.6 nie weryfikuje statusu super-administratora w endpointach createApiKey, generate2fa i disable2fa, co pozwala zwykłym menedżerom api.users.write na eskalację uprawnień do super-administratora. Atakujący mogą tworzyć klucze API powiązane z kontami super-administratorów lub usuwać uwierzytelnianie dwuskładnikowe (2FA) z kont super-administratorów, co prowadzi do pełnego przejęcia instancji.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.6 zawiera obejście autoryzacji. Klucze API mogą być tworzone z ograniczonym zakresem uprawnień, ale klasa ApiKeyAuthenticator nie odczytuje ani nie egzekwuje tych zakresów, zwracając pełny obiekt konta użytkownika. Oznacza to, że klucz z ograniczonymi uprawnieniami (np. tylko do odczytu) może wykonywać dowolne operacje zapisu, usuwania lub administracyjne, do których uprawniony jest właściciel klucza.

Wtyczka Grav API przed wersją 1.0.3 zawiera podatność polegającą na obejściu walidacji rozszerzenia pliku podczas przesyłania. Funkcja sprawdza tylko ostatnie rozszerzenie, co pozwala użytkownikowi z uprawnieniami api.media.write na przesłanie pliku z podwójnym rozszerzeniem, np. shell.php.jpg, omijając blokadę niebezpiecznych rozszerzeń. W rezultacie serwer WWW może wykonać taki plik jako PHP, prowadząc do zdalnego wykonania kodu.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 2.0.4 zawiera podatność polegającą na nieprawidłowym unieważnianiu sesji. Tokeny JWT są wydawane bez identyfikatora jti (JWT ID), co uniemożliwia ich odwołanie po stronie serwera.

Wtyczka Grav API (getgrav/grav-plugin-api) w wersji 1.0.0 zawiera podatność na nieograniczone przesyłanie plików w punkcie końcowym przesyłania awatara (/api/v1/users/user/avatar). Punkt końcowy weryfikuje tylko typ MIME zadeklarowany przez klienta (getClientMediaType) zaczynający się od 'image/' i nie sprawdza rzeczywistej zawartości pliku ani nie ogranicza wynikowego rozszerzenia, co pozwala uwierzytelnionemu użytkownikowi przechowywać dowolną treść — w tym kod PHP, SVG z osadzonym JavaScriptem oraz ładunki poliglotyczne — w katalogu user/accounts/avatars/ z przewidywalnymi nazwami plików. Bezpośredni dostęp HTTP do przechowywanych plików jest blokowany przez .htaccess (zwraca 403), ale pliki pozostają na dysku i mogą prowadzić do zdalnego wykonania kodu lub trwałego XSS w przypadku wystąpienia błędu path traversal lub błędnej konfiguracji serwera. Podatność została naprawiona w wersji 1.0.1.