Podatności safeurl

Podatność typu Time-of-check Time-of-use (TOCTOU) w Slab safeurl pozwala atakującemu kontrolującemu odpowiedzi DNS hostname na dotarcie do wewnętrznych celów sieciowych, które walidacja odrzuciła. Walidacja zwraca werdykt, a nie adres, który zatwierdziła, więc klienci HTTP dostarczani z biblioteką otrzymują oryginalny hostname i rozwiązują go ponownie przy wysyłaniu żądania. Atakujący kontrolujący autorytatywny DNS dla nazwy może odpowiedzieć na pierwsze zapytanie dozwolonym adresem, a na drugie zablokowanym, przez co żądanie dociera do celu, którego walidacja nigdy nie zatwierdziła. To samo okno otwiera się bez atakującego, gdy nazwa legalnie rozwiązuje się na różne adresy między zapytaniami, np. przy krótkim czasie życia rekordów lub rotacji między kilkoma adresami. Problem dotyczy safeurl od wersji 0.1.0.

Podatność Server-Side Request Forgery (SSRF) w Slab safeurl pozwala atakującemu kontrolującemu zwalidowany URL na dotarcie do wewnętrznych celów sieciowych, które biblioteka ma blokować. Tylko adresy IPv4 są dopasowywane do zarezerwowanych zakresów i blocklisty. Każdy inny adres jest traktowany jako niepasujący do niczego, więc cel odrzucony w formie IPv4 jest akceptowany, gdy jest zapisany jako adres IPv6, wpisy IPv6 w blockliście nigdy nie pasują, a host, który nie rozwiązuje się na żaden adres IPv4, jest akceptowany niezależnie od tego, gdzie wskazuje. Wdrożenia opierające się na allowliście są nienaruszone, ponieważ tam niedopasowany adres jest odrzucany. Problem dotyczy safeurl od wersji 0.1.0.

W bibliotece safeurl przed wersją 0.2.4 lista privateNetworks w ip.go pomija zakresy IPv6 64:ff9b:1::/48, 5f00::/16, 3fff::/20 oraz 100:0:0:1::/64. Gdy aplikacja włączy IPv6 poprzez EnableIPv6(true), cel atakującego w jednym z tych zakresów nie jest rozpoznawany jako niepubliczny i może przejść kontrolę SSRF. IPv6 jest domyślnie wyłączony, więc konfiguracje z EnableIPv6(false) nie są narażone.