Podatności @fastify/http-proxy

Wtyczka @fastify/http-proxy w wersjach 11.6.0–11.6.2 normalizuje literalne backslashe przed procentowym dekodowaniem ścieżki żądania, więc ścieżka kodująca backslashe i segmenty kropki przechodzi sprawdzenie, a dopiero potem zamienia się w sekwencje backslash i podwójna kropka. Gdy upstream działa na platformie traktującej backslash jako separator ścieżki, przekazane żądanie wychodzi poza skonfigurowany prefiks proxy i dociera do sąsiedniej lokalizacji upstream.

Wtyczka @fastify/http-proxy w wersjach 9.0.0–11.6.5 nie ponownie koduje zdekodowanych parametrów trasy wstawianych do rewritePrefix. Wartość parametru kodująca separator ścieżki wraz z ogranicznikiem fragmentu lub zapytania dekoduje się do rzeczywistych separatorów, co pozwala wstrzyknąć dodatkowe segmenty ścieżki upstream i pominąć wymagany sufiks. Nieuwierzytelniony zdalny atakujący może uzyskać dostęp do lokalizacji poza zamierzonym prefiksem, co prowadzi do obejścia ograniczeń ścieżki, a w zależności od upstreamu do SSRF lub obejścia autoryzacji.

Podatność w @fastify/http-proxy do wersji 11.5.0 włącznie powoduje, że prefiks żądania nie jest przepisywany, gdy segment prefiksu jest zakodowany w URL. Fastify dekoduje ścieżki dla dopasowania tras, ale request.url zachowuje oryginalną zakodowaną formę, a krok przepisywania prefiksu używa dosłownego zastąpienia ciągu względem zdekodowanego prefiksu. Żądanie kodujące jeden lub więcej znaków skonfigurowanego prefiksu pasuje do trasy, ale pomija przepisanie, przez co surowa zakodowana ścieżka jest przekazywana do upstreamu bez zmian, umożliwiając atakującemu dostęp do ścieżek upstreamu, które proxy miało ukryć za pomocą rewritePrefix, w tym wewnętrznych lub administracyjnych punktów końcowych.

@fastify/http-proxy przed wersją 11.6.2 nie weryfikuje ścieżek żądań HTTP pod kątem segmentów kropek z ukośnikami odwróconymi przed przekazaniem ich do skonfigurowanego upstreamu. Obsługa zwykłych żądań HTTP pomija walidację miejsca docelowego, którą wykonuje ścieżka WebSocket, a biblioteka reply-from odrzuca tylko trawersację z ukośnikami zwykłymi, więc żądanie zawierające segmenty kropek z ukośnikami odwróconymi może ominąć granicę ustawioną przez opcje prefix i rewritePrefix. Nieuwierzytelniony atakujący sieciowy może wykorzystać to do dotarcia do ścieżek upstreamu, które miały pozostać ukryte za proxy, co prowadzi do ujawnienia wewnętrznych punktów końcowych. Jest to problem trawersacji ścieżki (CWE-22). Użytkownicy powinni zaktualizować @fastify/http-proxy do wersji 11.6.2 lub nowszej.

W @fastify/http-proxy w wersjach od 9.4.0 do 11.5.0 brak walidacji rozdzielczości ścieżki WebSocket względem skonfigurowanego prefiksu przepisywania. Atakujący może użyć sekwencji nawigacji po ścieżce, aby ominąć prefiks i uzyskać dostęp do nieprzeznaczonych punktów końcowych.