Podatności ash_graphql

Podatność w ash_graphql umożliwia dostarczenie rekordów z jednej subskrypcji do innego subskrybenta. Błąd w obsłudze procesu powoduje, że dane z jednego przebiegu są błędnie używane w innym, co prowadzi do ujawnienia danych nieuprawnionemu odbiorcy.

Podatność w ash_graphql powoduje, że subskrypcje GraphQL dostarczają dane rekordów, do których subskrybent nie ma autoryzacji. Błąd w filtrowaniu wyników w batcherze pomija sprawdzanie uprawnień dla części powiadomień.

Podatność polegająca na alokacji zasobów bez limitów lub ograniczeń w ash_graphql umożliwia nieuwierzytelnionemu klientowi ominięcie skonfigurowanego limitu złożoności zapytań GraphQL i wymuszenie nieograniczonego odczytu bazy danych. Funkcja query_complexity/3 mnoży złożoność dziecka przez żądany rozmiar strony tylko wtedy, gdy mapa argumentów zawiera :limit (paginacja offsetowa). Połączenia Relay i paginacja keyset używają first i last, które nigdy nie pasują do tej klauzuli i przechodzą do catch-all, który zwraca child_complexity + 1. Zagnieżdżone zapytanie relay, takie jak posts(first: 500) { edges { node { comments(first: 500) { ... } } } }, jest więc oceniane jako trywialnie tanie, podczas gdy materializuje pełne rozwidlenie, omijając limit max_complexity Absinthe, który odrzuca równoważne zapytanie oparte na limicie. Poprawka dodaje klauzule first i last ograniczone do rozmiaru strony akcji. Problem dotyczy ash_graphql od 0.16.23 przed 1.11.0.

Podatność nieprawidłowej walidacji danych wejściowych w ash_graphql umożliwia nieuwierzytelnionemu klientowi doprowadzenie do awarii zapytania relay node(id: ...) z nieobsłużonym KeyError. Funkcja resolve_node/2 dekoduje dostarczony przez klienta globalny identyfikator za pomocą decode_relay_id/1, która tylko base64-dekoduje ciąg i dzieli go na : bez walidacji segmentu typu. Zdekodowany typ jest przekazywany bezpośrednio do Map.fetch!(type_to_domain_and_resource_map, type). Ponieważ fetch! podnosi błąd przy brakującym kluczu, identyfikator relay, którego segment typu jest prawidłowym atomem, ale nie jest typem wystawionym przez relay, przerywa resolver przed jego klauzulami resolve/2 i ich handlerami ratunkowymi, więc błąd nigdy nie staje się błędem GraphQL i może ujawnić stacktrace. Typowe nazwy zasobów są łatwe do odgadnięcia. Poprawka używa Map.fetch/2 i zwraca błąd Invalid node id dla nieznanych typów. Problem dotyczy ash_graphql od 0.27.0 przed 1.11.0.

Podatność nieprawidłowej autoryzacji w ash_graphql umożliwia uwierzytelnionemu subskrybentowi w jednej dzierżawie otrzymywanie rekordów innej dzierżawy przez subskrypcje GraphQL. Resolver subskrypcji autoryzuje każdy payload powiadomienia w pamięci: jego szybka ścieżka wywołuje Ash.can/3 z run_queries?: false, co ocenia filtr polityki odczytu na rekordzie w pamięci przez Ash.Expr.eval/2 i nigdy nie wysyła zapytania. Ash stosuje wielodzierżawczość w czasie budowania zapytania i prefiksu warstwy danych, a nie wewnątrz query.filter, więc oceniana polityka nie zawiera warunku dzierżawy, a powiadomienie dzierżawy B skierowane do subskrybenta dzierżawy A jest emitowane, gdy filtr polityki jest prawdziwy. Klauzula pojedynczego powiadomienia nie ma żadnej ochrony dzierżawy, a klauzula wsadowa sprawdza tylko głowę listy powiadomień, więc wpisy niebędące głową są autoryzowane wyłącznie w pamięci. Odczyt ograniczony do dzierżawy jest osiągany tylko wtedy, gdy ocena filtra nie powiedzie się. Problem dotyczy ash_graphql od 1.4.0 przed 1.11.0.

Podatność w ash_graphql umożliwia zdalnemu klientowi odczytanie wewnętrznych nazw pól, które aplikacja skonfigurowała do ukrycia w error_handler. Błąd w scalaniu ścieżki błędu powoduje, że ukryte nazwy pól są ponownie wstrzykiwane do odpowiedzi GraphQL.