Niewidzialny podatek: wykrycie i remediacja luki BOLA w API fintechu

Podczas audytu API dla fintechu (neo-bank, region CEE) znaleźliśmy klasyczną podatność BOLA (Broken Object Level Authorization) w nowej funkcji „Konta rodzinne”. Token JWT poprawnie uwierzytelniał użytkownika, ale część endpointów nie sprawdzała, czy ma on prawo do konkretnego zasobu. Zrobiliśmy bezpieczny proof-of-concept, zaproponowaliśmy naprawę na poziomie middleware + zmianę identyfikatorów na UUID i zestaw testów regresji, żeby ten błąd nie wrócił przy kolejnych wdrożeniach.

Kontekst: kim był klient i co się zmieniało

Klient to wiodący startup typu neo-bank w regionie CEE, przygotowujący się do ekspansji na rynki zachodnie. Produkt rośnie szybko, architektura opiera się o mikroserwisy, a tempo wdrożeń jest wysokie (czyli klasyczny przepis na „niewidzialny podatek” bezpieczeństwa, który pojawia się dopiero, gdy ktoś zaczyna intensywnie testować brzegowe scenariusze).

W momencie audytu wdrażana była nowa funkcja „Konta rodzinne”: użytkownicy mogli łączyć konta w ramach grupy, współdzielić wybrane widoki i wykonywać określone operacje w imieniu członków rodziny (w granicach nadanych uprawnień).

I tu zaczyna się ciekawa część, bo „granice uprawnień” w API potrafią być zdradliwe.

Problem: autentykacja działała, autoryzacja zasobów już nie zawsze

Z zewnątrz wszystko wyglądało poprawnie: użytkownik logował się, dostawał token JWT, a backend akceptował żądania.

Natomiast w części endpointów związanych z „Konto rodzinne” zabrakło weryfikacji autoryzacji na poziomie obiektu, czyli sprawdzenia, czy użytkownik ma prawo do konkretnego zasobu, który próbuje odczytać lub zmodyfikować.

To jest dokładnie to, co OWASP opisuje jako BOLA i nie bez powodu jest to numer 1 w OWASP API Security Top 10. W praktyce BOLA często nie wygląda jak „wielki, czerwony błąd”. To bardziej sytuacja typu: „hej, a co jeśli podmienię ID i backend nie zada żadnego pytania?”.

Jak pracowaliśmy: podejście Pentestica do audytu API

Zrobiliśmy audyt w sposób, który daje wynik techniczny i jednocześnie materiał do naprawy, nie tylko „listę problemów”.

1. Najpierw mapowanie API i przepływów biznesowych (szczególnie nowej funkcji).
2. Potem testy autoryzacji obiektów: odczyt i zapis dla zasobów typu „konto”, „profil”, „limit”, „beneficjent”, „historia operacji”, „uprawnienia w grupie”.
3. Na koniec warianty ról i uprawnień (właściciel, członek grupy, zaproszony, konto niepowiązane), bo BOLA często wychodzi dopiero przy nietypowej kombinacji ról.

Co znaleźliśmy: przykład mechanizmu BOLA

W skrócie: część endpointów ufała, że skoro użytkownik ma poprawny JWT, to ma też prawo do zasobu. A to są dwie różne rzeczy.

Minimalny, zanonimizowany proof-of-concept

Poniższy przykład pokazuje samą ideę (bez prawdziwych ścieżek i danych).

Żądanie poprawne (użytkownik A pobiera własny zasób):

GET /api/v1/family/accounts/24891/summary
Authorization: Bearer <JWT_uzytkownika_A>

Żądanie niepoprawne logicznie, ale akceptowane (użytkownik A podmienia ID na należące do użytkownika B):

GET /api/v1/family/accounts/24892/summary
Authorization: Bearer <JWT_uzytkownika_A>

Jeśli backend nie sprawdza relacji „czy konto 24892 należy do użytkownika A albo do jego grupy rodzinnej”, to odpowiedź może zawierać dane, które nie powinny opuścić kontekstu właściwego właściciela.

W naszym przypadku wektor ataku był wzmacniany przez to, że część identyfikatorów miała postać sekwencyjną (łatwą do zgadnięcia lub enumeracji). To nie jest przyczyna BOLA, ale świetny „dopalacz” dla atakującego.

Ryzyko biznesowe: dlaczego to jest groźne nawet bez „wielkiego wycieku”

W fintechu konsekwencje są zwykle konkretne:

• ekspozycja danych finansowych i danych osobowych (a to wchodzi w grę również w kontekście regulacyjnym),
• fraud i nadużycia (jeśli endpointy umożliwiają operacje, a nie tylko odczyt),
• utrata zaufania użytkowników, która w bankowości boli bardziej niż w większości branż.

W skali organizacji obsługującej setki tysięcy kont, nawet „wąska” luka w nowej funkcji potrafi urosnąć do bardzo dużego ryzyka.

Remediacja: co zaproponowaliśmy i jak to domknęliśmy

Naprawa BOLA nie polega na „dodaniu ifa w jednym miejscu”. Ona ma działać zawsze, nawet jak za 3 miesiące dojdzie nowy endpoint i ktoś o czymś zapomni.

Dlatego rekomendacja była dwutorowa:

1) Autoryzacja obiektów jako warstwa wspólna (middleware / policy enforcement)
Zamiast rozrzucać logikę uprawnień po kontrolerach, wdrożyliśmy podejście: każda operacja na zasobie przechodzi przez spójny mechanizm autoryzacji, który weryfikuje relację użytkownik → zasób → uprawnienia.

2) Zmiana identyfikatorów na UUID tam, gdzie miało to sens
UUID nie naprawia BOLA, ale ogranicza enumerację i utrudnia „zgadywanie” zasobów. W połączeniu z właściwą autoryzacją daje dużo bardziej odporny system.

Do tego dorzuciliśmy element, który w praktyce robi największą robotę długofalowo:

3) Testy regresji dla autoryzacji (negatywne scenariusze)
Wprowadziliśmy testy, które explicite sprawdzają: „użytkownik A nie może pobrać/zmienić zasobu użytkownika B”. Takie testy łapią powroty BOLA po refaktorach i nowych wdrożeniach.

Efekt: co się zmieniło po wdrożeniu poprawek

Po stronie klienta zostały wdrożone poprawki w API oraz zestaw testów, które stały się częścią pipeline’u. Najważniejsze zmiany były dwie:

1. Autoryzacja zasobów przestała być „opcją”, a stała się standardem egzekwowanym centralnie.
2. Zespół dostał jasny wzorzec, jak projektować nowe endpointy w funkcjach opartych o współdzielenie dostępu (rodziny, zespoły, organizacje).

To jest ten moment, w którym bezpieczeństwo przestaje być jednorazowym audytem, a zaczyna być praktyką inżynierską.

Wnioski

BOLA to nie egzotyka. To codzienność w API, szczególnie przy funkcjach „współdzielenia” i „delegowania”. Najlepsza obrona to nie „większa ostrożność”, tylko mechanizmy, które nie pozwalają się pomylić.

Jeśli budujesz lub rozwijasz API (fintech, e-commerce, SaaS), audyt pod kątem OWASP API Top 10 zwykle zwraca się szybciej, niż brzmi to w prezentacji.

Jak Pentestica może pomóc

Realizujemy testy penetracyjne aplikacji i audyty bezpieczeństwa API w sposób, który daje Ci:

• listę podatności z priorytetyzacją ryzyka,
• konkretne rekomendacje naprawcze (techniczne, nie ogólniki),
• oraz zestaw scenariuszy do testów regresji, żeby problem nie wrócił.

Jeśli chcesz, podeślij kontekst (stack, typ API, model uprawnień, czy są mikroserwisy), a zaproponujemy sensowny zakres audytu.