Podatności Parse Server

Parse Server przed 8.6.109 oraz 9.0.0 przed 9.10.6-alpha.1 zwraca przechowywane wartości pól w odpowiedziach aktualizacji obiektów bez sprawdzania uprawnień odczytu. Klienci, których uprawnienia klasowe lub ACL obiektu pozwalają na aktualizację, ale nie na odczyt, mogą zobaczyć dane obiektu, w tym wyniki operacji atomowych, wartości ustawiane przez Cloud Code oraz całe pola nadrzędne przy notacji kropkowej.

Parse Server od wersji 9.7.0 przed 9.10.5-alpha.10 zawiera błąd autoryzacji, który stosuje aktualizacje _Installation adresowane przez identyfikator obiektu do instalacji wskazanej w nagłówku X-Parse-Installation-Id. Gdy włączono protectedFieldsTriggerExempt, atakujący znający identyfikator obiektu innej instalacji może spowodować, że trigger beforeSave przetworzy chronione pola tej instalacji podczas zapisu w innym miejscu.

Parse Server przed wersjami 8.6.67 i 9.7.0-alpha.11 zawiera podatność, w której atakujący może ominąć kontrolę dostępu walidatora Cloud Function, dodając "prototype.constructor" do nazwy funkcji w URL. Powoduje to pominięcie całej kontroli dostępu, umożliwiając nieuwierzytelnionym wywołanie funkcji chronionych walidatorami.

Parse Server przed wersjami 8.6.3 i 9.1.1-alpha.4 jest podatny na atak, w którym nieautoryzowany napastnik może sfałszować token uwierzytelniający Google z algorytmem 'alg: "none"', co pozwala na logowanie się jako dowolny użytkownik powiązany z kontem Google bez znajomości jego danych uwierzytelniających.

Parse Server to open source backend, który można wdrożyć na dowolnej infrastrukturze działającej na Node.js. W wersjach przed 8.6.0-alpha.2, przepływ pracy GitHub CI jest wyzwalany w sposób, który przyznaje podwyższone uprawnienia GitHub Actions, dając dostęp do sekretów GitHub i uprawnień zapisu zdefiniowanych w przepływie pracy. Kod z forka lub skrypty cyklu życia mogą być potencjalnie uwzględnione. Dotyczy to tylko infrastruktury CI/CD repozytorium, w tym publicznych forków GitHub z włączonym GitHub Actions. Problem został naprawiony w wersji 8.6.0-alpha.2 oraz commitach 6b9f896 i e3d27fe.

Parse Server przed wersjami 5.5.2 i 6.2.1 jest podatny na zanieczyszczenie prototypu, co może prowadzić do zdalnego wykonania kodu poprzez parser BSON MongoDB.

Parse Server od wersji 9.7.0 przed 9.10.5-alpha.7 zawiera podatność ujawnienia informacji, która pozwala klientom otrzymywać wartości chronionych pól zapisanych przez triggery beforeSave przy użyciu kluczy notacji kropkowej. Gdy protectedFieldsSaveResponseExempt ma wartość false, klienci z uprawnieniami do tworzenia lub aktualizacji mogą odczytać wartości zapisane przez trigger pod chronionym polem w tym samym żądaniu.

Parse Server przed wersją 8.6.108 oraz 9.0.0 przed 9.10.5-alpha.9 zawiera podatność prototype pollution, ponieważ klucze kontrolowane przez użytkownika są rozwijane do obiektów bez sprawdzania własnych właściwości. Klienci z prawem zapisu do klasy mogą wysyłać klucze pól w notacji kropkowej lub nazwy wpisów ACL pasujące do wbudowanych członków obiektu, aby uszkodzić wbudowane funkcje, powodując awarię wszystkich żądań do czasu restartu serwera.

Parse Server przed 8.6.106 oraz 9.0.0 przed 9.10.5-alpha.7 nieprawidłowo obsługuje klucze notacji kropkowej z wartościami null lub undefined podczas budowania zapisywanego obiektu, więc zapis jest przechowywany, ale zwraca błąd i pomija wyzwalacze afterSave oraz zdarzenia LiveQuery. Klient z prawem zapisu może to wykorzystać do obejścia logowania audytowego, powiadomień i aktualizacji danych pochodnych.

Parse Server przed 8.6.107 oraz 9.0.0 przed 9.10.5-alpha.8 zwraca przechowywaną wartość pola przywróconego przez wyzwalacz beforeSave w odpowiedziach na aktualizację obiektu, nawet klientom bez prawa odczytu tego obiektu lub pola. Uwierzytelniony klient mogący aktualizować obiekt, którego wyzwalacz beforeSave przywraca pole (poprzez revert() lub walidator constant: true), może odczytać chronione wartości, w tym surowe authData MFA własnego konta, gdy włączone jest protectedFieldsTriggerExempt.

Parse Server w wersjach przed 8.6.105 oraz 9.0.0 przed 9.10.5-alpha.6 nie waliduje referencji do obiektu właściciela w zapytaniach relacji $relatedTo, więc podanie operatora zapytania zamiast identyfikatora obiektu omija kontrolę ACL obiektu właściciela. Klient z prawem odczytu przynajmniej jednego obiektu klasy właściciela może ujawnić, które czytelne obiekty są powiązane z obiektami właściciela, których nie może odczytać.

Parse Server w wersjach przed 8.6.101 oraz od 9.0.0 przed 9.10.4-alpha.4 zawiera podatność na brak autoryzacji w wdrożeniach MongoDB, która pozwala klientom bez klucza głównego usuwać przechowywany schemat dowolnej klasy. Nieuwierzytelnieni atakujący mogą wysyłać żądania usunięcia przez REST API do wewnętrznej kolekcji _SCHEMA, aby usunąć definicje pól, uprawnienia na poziomie klasy i pola chronione, narażając dane na nieautoryzowany odczyt i modyfikację.

Parse Server przed 8.6.100 oraz 9.0.0 przed 9.10.4-alpha.3 nie odrzuca zarezerwowanych nazw pól wewnętrznych w zapisach obiektów przez klientów, co pozwala klientom przechowywać lub czyścić pola wewnętrzne. Atakujący może zapisać zarezerwowane pole powodujące błędy odczytu obiektu w MongoDB, zakłócając zapytania dla wszystkich użytkowników, lub wyczyścić własny stan blokady konta i historię haseł, omijając polityki blokady i haseł.

Parse Server w wersjach przed 8.6.102 oraz od 9.0.0 przed 9.10.5-alpha.2 zawiera obejście uwierzytelniania, ponieważ metody validateSetUp, validateLogin i validateUpdate niestandardowych adapterów dziedziczących po AuthAdapter nigdy nie są wywoływane, a zamiast tego używana jest odziedziczona domyślna implementacja akceptująca dowolne authData. Atakujący mogą dostarczyć dowolne authData, aby zarejestrować się, połączyć tożsamości, zalogować się jako istniejący użytkownicy lub pominąć niestandardowe dodatkowe czynniki uwierzytelniania.

Parse Server przed 8.6.104 oraz 9.0.0 przed 9.10.5-alpha.5 zapisuje całe żądanie logowania z uprawnieniami master podczas wydawania kodu weryfikacyjnego SMS MFA. Użytkownik z włączonym SMS MFA może dołączyć dodatkowe pola do tego żądania, aby zmodyfikować pola zastrzeżone dla klucza master na własnym koncie, takie jak flaga weryfikacji e-mail lub wartości chronione przez beforeSave.

Parse Server przed 8.6.103 oraz 9.0.0 przed 9.10.5-alpha.4 zawiera podatność ujawnienia informacji w LiveQuery. Hash subskrypcji pomija ograniczenia obok operatora $or, w tym filtr właściciela _Session i ograniczenia beforeSubscribe, przez co różne subskrypcje są grupowane razem. Uwierzytelnieni klienci subskrybujący z zapytaniami $or mogą otrzymywać zdarzenia innych użytkowników, w tym tokeny sesji umożliwiające podszycie się.

Parse Server przed wersją 8.6.98 oraz 9.0.0 przed 9.10.3-alpha.1 nie wymusza uprawnień na poziomie klasy create i addField dla klasy _Session podczas tworzenia sesji. Uwierzytelniony użytkownik lub osoba posiadająca token sesji może wysłać żądania POST do /sessions lub /classes/_Session, aby utworzyć dodatkowe sesje i dodawać pola do _Session; sesje te nie są unieważniane po wylogowaniu oryginalnej sesji.

W Parse Server przed wersją 8.6.99 i od 9.0.0 przed 9.10.3-alpha.2 podczas aktualizacji użytkownika sprawdzane są warunki dotyczące konta docelowego przed autoryzacją wywołującego, a wynik jest odzwierciedlany w odpowiedzi. Nieautoryzowany wywołujący, z sesją lub bez, może potwierdzić zgadywane nazwy użytkowników lub adresy e-mail, a gdy ustawiono passwordPolicy.maxPasswordHistory lub doNotAllowUsername, także zgadywane bieżące lub poprzednie hasła, omijając blokadę konta.

Parse Server w wersjach przed 8.6.97 oraz 9.0.0 przed 9.10.2-alpha.6 nie obsługuje błędów pojawiających się podczas wysyłania e-maili weryfikacyjnych lub resetowania hasła, co powoduje zakończenie procesu serwera. Klient posiadający jedynie publiczne klucze aplikacji może zarejestrować się, zażądać e-maila weryfikacyjnego lub resetu hasła, gdy dostawca poczty odrzuca wiadomość, ogranicza liczbę żądań lub jest niedostępny, doprowadzając do awarii serwera.

Parse Server w wersji od 5.4.0 do 8.6.96 oraz od 9.0.0 do 9.10.2-alpha.5 współdzieli stan transakcyjny partii między równoczesnymi żądaniami, pozwalając żądaniu transakcyjnemu dowolnego klienta zakłócać zapisy do bazy danych innych klientów. W przypadku PostgreSQL lub zestawów replik i klastrów shardowanych MongoDB potwierdzone zapisy innych klientów są wycofywane, jeśli partia zawiedzie, a transakcje PostgreSQL mogą pozostać otwarte bezterminowo, powodując niepowodzenie kolejnych zapisów.

Parse Server przed wersją 8.6.93 oraz w gałęzi 9.0.0 przed 9.10.1-alpha.13 nie egzekwuje ochrony pól chronionych (authenticated, role lub grupy per-user) na zapytaniach count używających operatora $relatedTo, ujawniając rozmiar chronionych pól Relation. Uwierzytelniony użytkownik, który może odczytać właściciela obiektu, może połączyć liczby z ograniczeniem objectId jako wyrocznię członkostwa, aby ujawnić poufne członkostwa, takie jak prywatne grupy lub listy blokowane.

Podatność w Parse Server umożliwia nieuwierzytelnionym atakującym, posiadającym publiczne Application Id i klucz klienta, odtworzenie zapytania introspection z pamięci podręcznej Apollo Server, aby uzyskać schemat GraphQL, w tym prywatne nazwy klas i pól. Kontrola introspection jest stosowana tylko do bezpośrednio przesyłanych zapytań, nie do tych z pamięci podręcznej.

Parse Server przed wersją 8.6.95 oraz w gałęzi 9.0.0 przed 9.10.2-alpha.3 nie rozwiązuje referencji do plików pozbawionych URL przed przekazaniem obiektów do wyzwalaczy Cloud Code i LiveQuery, co powoduje nieprzechwycony wyjątek i zakończenie procesu. Atakujący, którzy mogą zapisywać do klasy z wyzwalaczami Cloud Code (save, find, delete) lub włączonym LiveQuery, w tym nieuwierzytelnieni użytkownicy, jeśli publiczny zapis lub rejestracja jest dozwolona, mogą zawiesić serwer lub przerwać kolejne żądania.

Parse Server w wersjach od 8.2.2 do 8.6.92 oraz od 9.0.0 do 9.10.1-alpha.12 zawiera podatność ujawnienia informacji, w której komunikaty błędów walidacji GraphQL ujawniają ukryte nazwy klas, gdy publiczna introspekcja jest wyłączona. Nieuwierzytelnieni atakujący posiadający jedynie publiczny Application Id mogą wysyłać spreparowane operacje wywołujące błędy nieznanego argumentu lub nieprawidłowej wartości enum, aby poznać klasy docelowe wskaźników i relacji.

Parse Server w wersjach >= 9.0.0 < 9.10.1-alpha.10 i >= 8.0.2 < 8.6.91 nie weryfikuje kodu autoryzacyjnego u dostawcy zewnętrznego podczas logowania z nazwą użytkownika i hasłem, gdy używane są adaptery uwierzytelniania oparte na kodzie (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo). Umożliwia to uwierzytelnionemu użytkownikowi o niskich uprawnieniach dołączenie dowolnej, niezweryfikowanej tożsamości dostawcy do swojego konta, a także przejęcie konta ofiary, która później zaloguje się przez tego dostawcę. Problem został naprawiony w wersjach 9.10.1-alpha.10 i 8.6.91.

Parse Server w wersjach >= 9.0.0 i < 9.10.1-alpha.8 oraz < 8.6.89 ocenia uprawnienie protectedFields na poziomie klasy względem niekompletnie rozwiązanego kontekstu wywołującego: role subskrybenta nie są rozwiązywane, a gdy subskrypcja nie dostarcza własnego tokenu sesji, ładunek zdarzenia jest redagowany względem tożsamości anonimowej, mimo że odczyt był autoryzowany względem połączonego użytkownika. W rezultacie maski pól zdefiniowane dla roli, uwierzytelnionych użytkowników lub konkretnego użytkownika nie są stosowane, więc uwierzytelniony subskrybent może otrzymywać wartości pól, które REST API poprawnie ukrywa. Dotyczy tylko klas z włączonym LiveQuery, które definiują protectedFields w grupach role:, authenticated lub per-user; maski w grupie public (*) są stosowane poprawnie. Naprawiono w 9.10.1-alpha.8 i 8.6.89.

Parse Server, backend typu open source, w wersjach przed 8.6.90 oraz od 9.0.0 przed 9.10.1-alpha.9, ma podatność w logice deduplikacji tokenów urządzeń dla rekordów instalacji. Logika ta nie sprawdza typu pól dostarczanych przez klienta przed użyciem ich do budowania zapytań do bazy danych. Nieuwierzytelniony atakujący, znający tylko publiczny identyfikator aplikacji, może przesłać wartości niebędące ciągami znaków, aby wstrzyknąć operatory zapytań, co powoduje, że czyszczenie deduplikacji (wykonywane z podwyższonymi uprawnieniami) usuwa wszystkie rejestracje urządzeń w aplikacji lub wybrany podzbiór.

Parse Server w wersjach do 8.6.87 oraz od 9.0.0 do 9.10.1-alpha.7 zawiera obejście uwierzytelniania we wbudowanym adapterze LDAP. Adapter przekazuje hasło dostarczone przez klienta do katalogu bez weryfikacji, czy hasło zostało podane, i traktuje każdą odpowiedź bez błędu jako dowód uwierzytelnienia. Atakujący bez uwierzytelnienia, znając nazwę użytkownika w katalogu, może uzyskać ważny token sesji dla tego konta, co prowadzi do przejęcia konta.

Parse Server w wersjach od 9.0.0 do 9.10.0-alpha.5 oraz od 8.2.2 do 8.6.86 zwraca komunikaty błędów walidacji GraphQL, które ujawniają nazwy wymaganych niestandardowych pól wejściowych, nawet gdy publiczna introspekcja jest wyłączona (graphQLPublicIntrospection: false, domyślnie). Klient posiadający tylko publiczny identyfikator aplikacji, bez sesji użytkownika, klucza głównego ani klucza konserwacji, może wywołać błędy walidacji, aby poznać nazwy wymaganych pól niestandardowych w klasach, które już zna po nazwie, częściowo omijając cel ukrywania schematu poprzez wyłączenie publicznej introspekcji. Nie są ujawniane żadne przechowywane dane, poświadczenia, nazwy pól opcjonalnych, nazwy klas nieprzywoływanych ani nazwy funkcji Cloud Code.

Parse Server w wersjach od 9.0.0 do 9.10.0-alpha.6 oraz od 8.2.2 do 8.6.87 ujawnia nazwy klas docelowych wskaźników i relacji poprzez komunikaty błędów walidacji GraphQL i wymuszania typów, gdy publiczna introspekcja schematu jest wyłączona (graphQLPublicIntrospection: false, domyślnie). Ponieważ błędy te są generowane przed uwierzytelnieniem, autoryzacją lub uruchomieniem resolvera, nieuwierzytelniony klient posiadający tylko publiczny identyfikator aplikacji może wywołać błędy na polach wskaźników lub relacji, aby zrekonstruować ukryte nazwy klas schematu, częściowo omijając ochronę ukrywania schematu. Ujawniane są tylko metadane schematu (nazwy klas); żadne dane obiektów, poświadczenia ani rekordy użytkowników nie są ujawniane.

Podatność w Parse Server w wersjach >= 9.0.0 przed 9.10.0-alpha.4 i wersjach przed 8.6.85 powoduje ujawnienie schematu. Mimo wyłączenia publicznej introspekcji GraphQL, błędy zmiennych ujawniają sugestie 'Did you mean ...?', co pozwala nieuwierzytelnionemu atakującemu na odtworzenie ukrytych identyfikatorów schematu.

Parse Server w wersjach od 9.0.0 do 9.10.0-alpha.2 oraz od 8.6.83 i wcześniejszych zawiera podatność na trwałe XSS. Nieprawidłowo sformowany Content-Type pliku (np. 'image//svg+xml') omija blokadę rozszerzeń i jest przechowywany bez zmian, co w przypadku adapterów S3, GCS lub Azure powoduje, że przeglądarka interpretuje plik jako HTML i wykonuje osadzony skrypt.

Podatność w Parse Server umożliwia subskrybentowi LiveQuery odbieranie wartości pól obiektu, do których nie ma uprawnień odczytu. Problem występuje, gdy pojedyncza operacja zapisu zmienia zarówno pole obiektu, jak i uprawnienia ACL subskrybenta, powodując błędne przetwarzanie zdarzeń leave i enter.

Podatność w Parse Server pozwala na blokadę pętli zdarzeń Node.js poprzez wysłanie głęboko zagnieżdżonych operatorów zapytań $or, $and i $or w REST API lub LiveQuery. Przetwarzanie takich zapytań może prowadzić do wykładniczego czasu wykonania, co uniemożliwia obsługę innych żądań.

Podatność w Parse Server umożliwia ominięcie domyślnej blokady rozszerzeń plików poprzez przesłanie pliku z niestandardowym lub złożonym rozszerzeniem oraz niebezpiecznym typem treści. Pozwala to adapterom pamięci masowej, takim jak S3 i GCS, na serwowanie aktywnej treści dostarczonej przez atakującego, co prowadzi do przechowywanego cross-site scripting (XSS).

W Parse Server przed wersjami 8.6.80 i 9.9.1-alpha.6 występowała podatność, która pozwalała na odczytanie członkostwa w polu relacyjnym za pomocą operatora $relatedTo, nawet gdy pole to było ukryte dla klienta. Umożliwiało to nieautoryzowanym klientom enumerację obiektów powiązanych z chronioną relacją.

Parse Server w wersjach od 9.8.0 do przed 9.9.1-alpha.5 ma lukę, która pozwala na ujawnienie wrażliwych danych użytkowników przez punkty końcowe /login i /verifyPassword, gdy włączono MFA i zablokowano dostęp do klasy _User. W przypadku odmowy dostępu do danych użytkownika, serwer zwraca surowe dane z bazy, co może prowadzić do ujawnienia tajnych informacji, takich jak sekrety MFA i kody odzyskiwania.

Parse Server przed wersjami 8.6.79 i 9.9.1-alpha.4 pozwalał na obejście domyślnej listy blokowanych rozszerzeń plików poprzez dodanie kropki na końcu nazwy pliku. To umożliwia atakującym przesyłanie plików z niebezpiecznymi typami MIME, co prowadzi do możliwości wykonania ataków XSS.

Parse Server w wersjach od 9.8.0 do przed 9.9.1-alpha.3 ma lukę, która pozwala na obejście listy dozwolonych tras API. Zewnętrzni klienci mogą wysyłać sub-zapytania do tras, które nie zostały uwzględnione w tej liście, co stwarza ryzyko nieautoryzowanego dostępu.

Parse Server przed wersjami 8.6.78 i 9.9.1-alpha.2 ujawnia metadane schematu przez komunikaty o błędach walidacji GraphQL, co pozwala nieautoryzowanym użytkownikom na rekonstrukcję nazw klas i pól.

Parse Server przed wersjami 8.6.77 i 9.9.1-alpha.1 jest podatny na atak, w którym nieautoryzowany użytkownik może wysłać złośliwe żądanie HTTP, co prowadzi do nadmiernego zużycia CPU na serwerze.

W Parse Server (przed 8.6.76 i 9.9.0-alpha.2) warunek wyścigu w ścieżce logowania MFA SMS z jednorazowym hasłem (OTP) pozwala dwóm równoczesnym żądaniom /login z tym samym OTP na sukces i otrzymanie ważnych tokenów sesji, naruszając jednorazowość OTP. Wykorzystanie wymaga posiadania hasła ofiary i przechwycenia aktywnego OTP SMS oraz wyścigu z legalnym żądaniem logowania, więc powierzchnia ataku jest wąska.

Parse Server jest podatny na ujawnienie chronionych pól sesji poprzez endpoint GET /sessions/me. Endpoint ten zwraca pola _Session, które administrator skonfigurował jako chronione, podczas gdy inne endpointy poprawnie je usuwają.

Parse Server to oprogramowanie backendowe typu open source. W wersjach przed 9.8.0-alpha.6 i 8.6.74 czas odpowiedzi endpointu logowania różni się w zależności od tego, czy podana nazwa użytkownika lub e-mail istnieje w bazie. Gdy użytkownik nie istnieje, serwer odpowiada natychmiast; gdy istnieje, ale hasło jest błędne, najpierw wykonywane jest porównanie bcrypt, co dodaje opóźnienie. Różnica czasowa pozwala nieuwierzytelnionemu atakującemu na enumerację prawidłowych nazw użytkowników.

Podatność w Parse Server (wersje przed 8.6.73 i 9.7.1-alpha.4) polegająca na możliwości przesłania pliku z rozszerzeniem dozwolonym (np. .txt) ale z nagłówkiem Content-Type niezgodnym z rozszerzeniem (np. text/html). Niektóre adaptery pamięci masowej (S3, GCS) serwują plik z podanym Content-Type, co może prowadzić do ataków.

Parse Server przed wersjami 8.6.71 i 9.7.1-alpha.1 pozwala na pobieranie plików przez żądania HTTP Range z pominięciem triggera afterFind(Parse.File) i walidatorów, gdy adapter pamięci masowej obsługuje strumieniowanie (np. domyślny GridFS). Umożliwia to dostęp do plików chronionych logiką autoryzacji.

Parse Server przed wersjami 8.6.63 i 9.7.0-alpha.7 zwraca niesanitowane dane uwierzytelniające z endpointu weryfikacji hasła, w tym sekrety MFA TOTP, kody odzyskiwania i tokeny OAuth. Atakujący znający hasło użytkownika może wyodrębnić sekret MFA i generować ważne kody MFA.

W Parse Server przed wersjami 8.6.70 i 9.7.0-alpha.18 uwierzytelniony użytkownik z uprawnieniami find na poziomie klasy może ominąć ustawienie protectedFields w subskrypcjach LiveQuery. Wysyłając subskrypcję z operatorem $or, $and lub $nor jako obiekt podobny do tablicy, ochrona jest pomijana, co pozwala na odczytanie chronionych pól.

Parse Server przed wersjami 8.6.69 i 9.7.0-alpha.14 pozwala uwierzytelnionemu użytkownikowi na ominięcie ochrony niezmienności pól sesji (expiresAt, createdWith) poprzez wysłanie wartości null w żądaniu PUT do punktu końcowego aktualizacji sesji. Umożliwia to unieważnienie wygaśnięcia sesji, czyniąc ją ważną bezterminowo i omijając skonfigurowane zasady długości sesji.

Parse Server przed wersjami 8.6.68 i 9.7.0-alpha.12 ma podatność na atak DoS przez GraphQL. Wysyłając spreparowane zapytanie z binarnym rozgałęzieniem fragmentów, nieuwierzytelniony atakujący może zablokować pętlę zdarzeń Node.js na kilka sekund, uniemożliwiając działanie innym użytkownikom. Problem dotyczy tylko instalacji z włączonymi opcjami requestComplexity.graphQLDepth lub requestComplexity.graphQLFields.