< Powrót do Artykułów
◆ Zbiorcze case study · pentest SaaS B2B

Pięć osobnych błędów.
Jeden krytyczny łańcuch.

Jak podczas testów aplikacji webowych i API łączymy informacje ujawnione przez frontend, błędy autoryzacji obiektowej, eksporty asynchroniczne i linki udostępniania w realną ścieżkę dostępu do danych innej organizacji.

FORMAT case study zbiorcze TRYB black-box + konto użytkownika OBSZAR aplikacja / API / SaaS DANE w pełni syntetyczne
TL;DR · najważniejsze fakty

Pięć pozornie niezależnych słabości utworzyło jedną ścieżkę ataku

TL;DR: w syntetycznym środowisku SaaS połączenie informacji z frontendu, BOLA/IDOR, przewidywalnego identyfikatora zadania eksportu i zbyt szerokich uprawnień linku udostępniania umożliwiło dostęp do danych innego tenanta. Każdy element osobno miał ograniczony wpływ; dopiero ręczne połączenie wyników pokazało rzeczywiste ryzyko biznesowe.

  • Zakres: aplikacja webowa, REST API i asynchroniczny eksport danych.
  • Model: black-box z kontem zwykłego użytkownika; wyłącznie autoryzowane testy.
  • Kluczowa klasa błędu: Broken Object Level Authorization (BOLA/IDOR) i brak spójnej separacji tenantów.
  • Rezultat: potwierdzony łańcuch wpływu na poufność danych, opisany na danych całkowicie syntetycznych.
  • Naprawa: autoryzacja obiektowa po stronie serwera na każdym etapie, nieprzewidywalne identyfikatory oraz krótkotrwałe, minimalnie uprzywilejowane linki.

Autor: Michał Błaszczak · · BSTA sp. z o.o.

Źródła metodyczne: OWASP API Security, OWASP ASVS oraz PTES. Źródła definiują klasy ryzyka i sposób weryfikacji; wnioski oraz opis łańcucha są autorską analizą zespołu BSTA.

5
warstw
łańcucha
API1
broken object
authorization
B2B
separacja
tenantów
HIGH
łączny
wpływ
Zasady anonimizacji

To nie jest opis jednego klienta

Materiał łączy powtarzalne mechanizmy obserwowane w kilku autoryzowanych testach i opisane również w naszych osobnych analizach technicznych. Zostały połączone w jeden scenariusz edukacyjny, aby pokazać sposób myślenia napastnika i pentestera.

Nazwy organizacji, systemów, hostów, endpointów, ról, identyfikatorów i danych zostały usunięte lub zastąpione wartościami syntetycznymi. Przykłady nie pozwalają odtworzyć środowiska żadnego klienta.

Etap 1 · powierzchnia ataku

Frontend zdradza mapę, której nie pokazuje interfejs

Test zaczyna się od tego, co może zobaczyć anonimowy użytkownik: kodu HTML, plików JavaScript, konfiguracji klienta, nazw tras i sposobu komunikacji z API. Sama obecność endpointu nie jest podatnością, ale skraca drogę do miejsc wymagających ręcznej weryfikacji.

synthetic frontend review
GET /_next/static/chunks/app-********.js [+] /api/v2/reports/{reportId} [+] /api/v2/reports/{reportId}/export [+] /api/v2/jobs/{jobId}/result [+] /api/v2/share/{shareId} # Wniosek: sprawdzić cały cykl życia raportu, nie tylko widok w UI.
Etap 2 · model uprawnień

Poprawny token nie oznacza prawa do każdego obiektu

Po otrzymaniu zwykłego konta użytkownika budujemy macierz relacji: użytkownik → organizacja → projekt → raport → eksport → link udostępniania. Następnie wykonujemy testy negatywne pomiędzy dwoma syntetycznymi tenantami.

authorization matrix
user_RED -> tenant_RED -> report_RED user_BLUE -> tenant_BLUE -> report_BLUE Test: token_RED + report_BLUE Expected: 403 albo 404 Observed in scenario: 200 OK
Kluczowa lekcja

Uwierzytelnienie odpowiada na pytanie „kim jesteś”. Autoryzacja obiektowa musi dodatkowo odpowiedzieć „czy ten konkretny obiekt należy do organizacji, do której masz dostęp”.

Etap 3 · BOLA

Podmiana identyfikatora ujawnia dane innego tenant-a

synthetic request / response
GET /api/v2/reports/report_BLUE_001 HTTP/2 Authorization: Bearer token_user_RED HTTP/2 200 OK {"reportId":"report_BLUE_001","tenantId":"tenant_BLUE"} [!] Token ważny, ale brak sprawdzenia relacji tenant → object.

Pojedynczy odczyt potwierdza klasę problemu, lecz nie kończy testu. Sprawdzamy listy, załączniki, wersje historyczne, komentarze, raporty PDF/XLSX, funkcje share oraz zadania wykonywane poza głównym requestem.

Etap 4 · ścieżki poboczne

Eksport i link share omijają poprawki głównego endpointu

Częstym błędem jest poprawienie kontroli na ekranie raportu, ale pozostawienie słabszej walidacji w generatorze eksportu, kolejce zadań albo mechanizmie linków czasowych.

async export chain
POST /api/v2/reports/report_BLUE_001/export Authorization: Bearer token_user_RED HTTP/2 202 Accepted {"jobId":"job_SYNTHETIC_001"} GET /api/v2/jobs/job_SYNTHETIC_001/result HTTP/2 200 OK Content-Type: application/pdf
Pojedynczy błąd może wyglądać niepozornie.
Łańcuch pokazuje rzeczywisty wpływ biznesowy.
Dlaczego automat tego nie widzi

Skaner znajduje endpointy. Pentester rozumie relacje

Automatyczne narzędzia dobrze wykrywają część problemów technicznych, ale zwykle nie znają modelu tenantów, oczekiwanych ról ani znaczenia biznesowego eksportu. Do potwierdzenia łańcucha potrzebne są dwa kontrolowane konteksty użytkowników, macierz uprawnień i ręczne porównanie odpowiedzi.

Co dokumentujemy w raporcie

Warunki odtworzenia, zanonimizowane request/response, zakres dostępnych obiektów, wpływ na poufność i integralność, root cause, zalecenie naprawcze oraz testy regresyjne dla wszystkich wariantów endpointu.

Naprawa

Autoryzacja musi obejmować cały cykl życia obiektu

1. Zakresuj zapytania tenantem. Obiekt powinien być pobierany jednocześnie po identyfikatorze i tenantach dozwolonych dla bieżącego użytkownika.

2. Nie ufaj tenantId z requestu. Kontekst organizacji musi wynikać z uwierzytelnionej sesji i danych po stronie serwera.

3. Waliduj ponownie zadania asynchroniczne. Eksport i wynik joba wymagają tej samej kontroli obiektowej co główny endpoint.

4. Ogranicz linki share. Krótki czas życia, możliwość unieważnienia, minimalny zakres danych i rejestrowanie dostępu.

5. Dodaj testy negatywne. Każdy endpoint z identyfikatorem obiektu powinien mieć test dla użytkownika z innego tenant-a.

Wniosek

Wartość pentestu powstaje pomiędzy podatnościami

Najgroźniejsze scenariusze rzadko kończą się na jednym alertcie. Rzetelny test pokazuje, jak osoba atakująca przechodzi od publicznej informacji, przez konto o najniższych uprawnieniach, do obiektu, eksportu i danych należących do innej organizacji.

◆ BSTA · testpenetracyjny.pl

Chcesz sprawdzić separację klientów w aplikacji lub API?

Przetestujemy model tenantów, role, eksporty, załączniki, joby asynchroniczne, linki udostępniania i ścieżki niewidoczne w interfejsie.

Zapytaj o zakres pentestu →
Raport techniczny i executive summary · retest po poprawkach · pełna anonimizacja danych