Wprowadzenie do problemu / definicja
W platformie Probo w wersji 0.222.2 oraz starszych ujawniono podatność typu IDOR, która w środowisku wielodzierżawnym przyjmuje formę naruszenia izolacji między tenantami. Oznacza to, że obiekty należące do jednej organizacji mogą zostać nieprawidłowo powiązane lub odczytane w kontekście innej organizacji, co otwiera drogę do nieautoryzowanego ujawnienia danych.
Problem jest szczególnie istotny w systemach współdzielonych przez wielu klientów, gdzie separacja danych stanowi jeden z podstawowych filarów bezpieczeństwa. W tym przypadku błąd nie dotyczy wyłącznie pojedynczego rekordu, lecz samej logiki egzekwowania granic między tenantami.
W skrócie
Podatność została opisana jako cross-tenant IDOR i powiązana z identyfikatorem CVE-2026-63505. Według dostępnych informacji podatne są wydania Probo do wersji 0.222.2 włącznie, natomiast poprawkę wdrożono w wersji 0.223.1.
- Typ podatności: IDOR prowadzący do naruszenia izolacji między tenantami
- Produkt: Probo
- Wersje podatne: do 0.222.2 włącznie
- Wersja naprawiona: 0.223.1
- Główne ryzyko: ujawnienie danych między organizacjami współdzielącymi jedną instancję
Kontekst / historia
IDOR od lat pozostaje jedną z najczęściej spotykanych klas błędów autoryzacyjnych w aplikacjach webowych. W środowiskach wielodzierżawnych jego skutki są jednak zwykle znacznie poważniejsze, ponieważ nawet ograniczone obejście kontroli dostępu może prowadzić do naruszenia poufności danych należących do innych klientów.
W opisywanym przypadku problem został nagłośniony publicznie wraz z technicznym opisem mechanizmu błędu. To ważny przykład pokazujący, że zagrożenie nie zawsze wynika z prostego manipulowania przewidywalnym identyfikatorem. Często źródłem podatności jest niespójność między warstwą walidacji, logiką zapisu relacji oraz sposobem późniejszego ładowania obiektów powiązanych.
Analiza techniczna
Mechanizm podatności opiera się na dwóch błędach logicznych: luce podczas zapisu relacji oraz luce podczas odczytu danych. Taka kombinacja prowadzi do sytuacji, w której rekord jednego tenanta może referencjonować zasób należący do innego tenanta, a następnie doprowadzić do jego ujawnienia.
Pierwszy etap można określić jako problem w procesie zapisu. Aplikacja dopuszczała utworzenie lub aktualizację obiektu typu finding w organizacji A z identyfikatorem obiektu risk należącego do organizacji B. Zabrakło skutecznej walidacji tenant-aware po stronie relacji, przez co integralność powiązań między rekordami nie była odpowiednio wymuszana.
Drugi etap dotyczył odczytu. System poprawnie autoryzował obiekt nadrzędny, ale następnie pobierał powiązany obiekt zależny na podstawie zakresu wynikającego z jego własnego identyfikatora, a nie z kontekstu bieżącego żądania. W praktyce oznaczało to niejawne przełączenie kontekstu do innego tenanta i obejście założeń izolacji danych.
Z perspektywy bezpieczeństwa jest to klasyczny przykład niespójnego modelu autoryzacji w architekturze warstwowej. Jeśli jedna część aplikacji akceptuje relację międzyobiektową bez sprawdzenia przynależności tenantowej, a druga ufa identyfikatorowi obiektu podrzędnego podczas odczytu, powstaje ścieżka do cross-tenant data exposure.
Konsekwencje / ryzyko
Najważniejszym skutkiem podatności jest naruszenie poufności danych pomiędzy organizacjami korzystającymi z tej samej instancji systemu. W zależności od implementacji i modelu danych mogło to obejmować informacje dotyczące ryzyk, klasyfikacji, notatek, procesów zgodności oraz innych rekordów powiązanych z modułami GRC.
Ryzyko biznesowe takich luk jest wysokie, nawet jeśli nie prowadzą one bezpośrednio do wykonania kodu lub usunięcia danych. W środowiskach wielodzierżawnych samo przełamanie izolacji tenantów może skutkować incydentem zgodności, utratą zaufania klientów, koniecznością przeprowadzenia analiz śledczych, a w niektórych przypadkach także obowiązkami notyfikacyjnymi.
- Ujawnienie danych innej organizacji
- Naruszenie modelu bezpieczeństwa platformy SaaS lub self-hosted multi-tenant
- Ryzyko incydentów regulacyjnych i audytowych
- Potencjalna utrata reputacji operatora platformy
Rekomendacje
Organizacje korzystające z Probo powinny w pierwszej kolejności zweryfikować używaną wersję i zaplanować aktualizację do co najmniej 0.223.1. Jeśli środowisko nadal działa na wersjach podatnych, warto traktować sprawę jako potencjalne naruszenie izolacji danych i odpowiednio podnieść priorytet działań.
- Przeprowadzić aktualizację do wersji 0.223.1 lub nowszej
- Zweryfikować poprawność relacji między obiektami przechowującymi identyfikatory zasobów powiązanych
- Wymusić walidację tenant-aware podczas tworzenia i aktualizacji rekordów
- Sprawdzić, czy warstwa odczytu korzysta z kontekstu autoryzacyjnego żądania, a nie wyłącznie z identyfikatora obiektu docelowego
- Przejrzeć resolvery, ORM-y, dataloadery oraz mechanizmy cache pod kątem niespójności autoryzacyjnych
- Dodać testy bezpieczeństwa obejmujące scenariusze cross-tenant dla zapisu i odczytu
- Przeanalizować logi aplikacyjne i audytowe pod kątem nietypowych odwołań do rekordów spoza właściwego zakresu organizacyjnego
- Rozważyć dodatkowe ograniczenia integralności na poziomie bazy danych
Dla zespołów AppSec i deweloperskich to również sygnał, aby w przeglądach kodu uwzględniać nie tylko pytanie, czy użytkownik ma dostęp do obiektu nadrzędnego, ale także czy wszystkie powiązane rekordy są ładowane i walidowane w tym samym, poprawnym kontekście tenantowym.
Podsumowanie
Luka w Probo do wersji 0.222.2 pokazuje, że podatności IDOR w aplikacjach wielodzierżawnych często wynikają z błędów logicznych trudniejszych do wychwycenia niż prosta manipulacja identyfikatorem. Połączenie braku walidacji relacji cross-tenant i niewłaściwego zakresowania podczas odczytu może doprowadzić do realnego ujawnienia danych między organizacjami.
Dla operatorów i administratorów oznacza to konieczność szybkiej aktualizacji, przeglądu integralności relacji oraz wdrożenia testów bezpieczeństwa ukierunkowanych na izolację tenantów. To właśnie spójność autoryzacji między warstwami aplikacji pozostaje jednym z najważniejszych elementów ochrony środowisk multi-tenant.