Platforma telematyczna i API.
Czy klient A może zobaczyć flotę klienta B?

Największe ryzyko ukrywało się w API integracyjnym

W skrócie: scenariusz zbudowany z mechanizmów występujących w autoryzowanych testach transportowych pokazał, że token poprawnie identyfikował klienta, ale część endpointów przyjmowała obcy identyfikator pojazdu lub zlecenia. Pozwalało to odczytać syntetyczną historię lokalizacji, dokument i status zadania należące do innego tenanta.

• Kluczowe klasy błędów: BOLA, masowe przypisanie pól, zbyt szeroki token integracyjny i brak ograniczenia zapytań.
• Wpływ: ujawnienie tras, zleceń i dokumentów oraz możliwość zmiany wybranych danych operacyjnych.
• Bezpieczeństwo: bez wysyłania poleceń do rzeczywistych pojazdów i bez wpływu na realizowane przewozy.

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

Dane i topologia są syntetyczne

Nazwy operatora, klientów, urządzeń, pojazdów, tras i endpointów zostały usunięte. Case study jest kompozytem mechanizmów z autoryzowanych testów i nie opisuje jednego wdrożenia. Prezentowane identyfikatory i odpowiedzi API są przykładowe.

Token był ważny, lecz obiekt nie należał do jego organizacji

Test objął nie tylko panel webowy. Te same operacje wykonaliśmy przez backend aplikacji mobilnej, API partnerów i funkcje eksportu. Pozwoliło to wykryć niespójną autoryzację pomiędzy kanałami.

Priorytety naprawcze

Autoryzacja jako wspólna warstwa platformy

1. Sprawdzenie tenant-a i uprawnienia do obiektu w centralnym komponencie autoryzacji.
2. Osobne, minimalne zakresy OAuth dla panelu, aplikacji kierowcy, partnera i urządzenia.
3. Lista dozwolonych pól w operacjach aktualizacji; odrzucanie mass assignment.
4. Rate limiting, wykrywanie sekwencyjnych identyfikatorów i alerty o dostępie między tenantami.
5. Testy regresyjne dla każdej kombinacji rola–tenant–obiekt–operacja.

Pentest platformy TMS, telematyki, aplikacji kierowcy i API

Platforma transportowa łączy dane o pojazdach, kierowcach, trasach, zleceniach, dokumentach, lokalizacji i rozliczeniach. Dlatego test objął panel dyspozytora, backend aplikacji mobilnej, publiczne i partnerskie API, tokeny urządzeń, eksporty oraz integracje z systemami klientów. Każdy kanał musiał egzekwować tę samą granicę organizacji.

Weryfikowaliśmy uwierzytelnianie, sesje, OAuth, role, BOLA/IDOR, BFLA, mass assignment, rate limiting, upload dokumentów, webhooki i bezpieczeństwo danych lokalnych aplikacji. Testy prowadziliśmy na syntetycznych pojazdach, zleceniach i trasach. Nie wysyłaliśmy poleceń do rzeczywistych urządzeń.

• dyspozytor: podgląd floty, planowanie, eksport i delegowanie uprawnień;
• kierowca: zadania, dokumenty, potwierdzenia, lokalizacja i sesja mobilna;
• partner: token integracyjny, zakresy OAuth, dostęp zbiorczy i webhooki;
• urządzenie: identyfikacja, klucze, komendy, aktualizacje i możliwość podszycia;
• tenant: separacja klienta w API, cache, wyszukiwaniu, raportach i zadaniach w tle.

Jak wykryliśmy BOLA pomiędzy flotami dwóch klientów

Utworzyliśmy dwa kontrolowane tenanty z osobnymi pojazdami i zleceniami. Dla każdej operacji porównywaliśmy odpowiedź prawidłową z próbą wskazania obiektu drugiej organizacji. Panel ukrywał obce rekordy, ale część endpointów API opierała decyzję na ważności tokenu i istnieniu identyfikatora.

Bezpieczny PoC ograniczył się do syntetycznej historii lokalizacji i przygotowanego dokumentu przewozowego. Następnie sprawdziliśmy operację zapisu na polu pozbawionym wpływu na realny przewóz. Test ujawnił także, że token integracyjny miał szersze zakresy niż wymagała jego funkcja, a odpowiedzi ułatwiały sekwencyjną enumerację.

Przyczyną nie był jeden „niechroniony URL”, ale brak wspólnej polityki autoryzacji. Niektóre mikroserwisy wiązały obiekt z tenantem, inne zakładały, że zrobiła to brama API. Naprawa musiała objąć architekturę i testy regresyjne, a nie pojedynczy endpoint.

Co oznacza dostęp do trasy, zlecenia i dokumentu innej firmy

Dane telematyczne mogą ujawniać lokalizację pojazdu, harmonogram, klienta, miejsce załadunku i wzorce działania. Dostęp do dokumentów przewozowych narusza poufność kontrahentów, a możliwość zmiany danych operacyjnych może prowadzić do błędnych decyzji dyspozytora lub sporów rozliczeniowych.

Ryzyko ocenialiśmy osobno dla odczytu, modyfikacji i masowej enumeracji. Uwzględniliśmy liczbę tenantów, przewidywalność identyfikatorów, zakres tokenu i możliwość automatyzacji. Rekomendacje obejmowały także detekcję: wiele obcych identyfikatorów, nietypowy eksport, token używany z nowego źródła i operacje na wielu flotach.

Dla zarządu przygotowaliśmy podsumowanie wpływu na poufność kontraktów, ciągłość operacji, bezpieczeństwo ładunku i reputację platformy. Zespół techniczny otrzymał żądania, odpowiedzi, warunki odtworzenia i wzorzec testu automatycznego.

Kiedy zamówić pentest systemu transportowego lub logistycznego

Test warto wykonać przed wdrożeniem nowej aplikacji kierowcy, po dodaniu API dla klientów, po migracji telematyki, po połączeniu z TMS/WMS/ERP, przed uruchomieniem białej etykiety dla kolejnego tenant-a oraz po zmianie modelu OAuth. Ważnym momentem jest również przejęcie innego operatora lub konsolidacja kilku flot.

Do wyceny potrzebujemy liczby aplikacji, ról i tenantów, listy głównych obiektów, dokumentacji API, integracji, typów urządzeń oraz zasad bezpiecznego testowania komend. Możemy przygotować kontrolowaną flotę testową i podpisać NDA.

Zobacz: pentest API od 1 999 zł, test aplikacji mobilnej, test panelu webowego i monitoring SOC/SIEM.

Najczęstsze pytania o pentest telematyki, TMS i API logistycznego

Czy testujecie separację klientów w platformie SaaS?

Tak. Budujemy macierz tenant–rola–obiekt–operacja i sprawdzamy API, panel, aplikację, raporty, cache, eksporty i procesy asynchroniczne.

Czy można bezpiecznie testować lokalizację pojazdów?

Tak. Używamy syntetycznych pojazdów, tras i danych GPS albo uzgodnionych rekordów kontrolnych. Nie śledzimy rzeczywistych osób poza zakresem.

Czy pentest obejmuje aplikację kierowcy?

Może obejmować Android/iOS, przechowywanie danych, sesję, deep links, komunikację, pinning, WebView, uprawnienia urządzenia i backend API.

Co to jest BOLA w telematyce?

BOLA występuje, gdy poprawnie zalogowany użytkownik może wskazać identyfikator pojazdu, zlecenia lub dokumentu innego klienta, a backend nie sprawdza jego przynależności.

Czy wysyłacie polecenia do urządzeń?

Tylko do kontrolowanych urządzeń testowych i po wyraźnym uzgodnieniu. W produkcji zwykle potwierdzamy możliwość wywołania bez realizowania komendy wpływającej na pojazd.

Jak sprawdzacie tokeny integracyjne?

Oceniamy zakresy, ważność, rotację, wiązanie z klientem, limity, możliwość użycia poza integracją i dostęp do funkcji administracyjnych.

Ile trwa pentest platformy transportowej?

Realizacja testu zajmuje od 5 dni roboczych. Czas zależy od liczby aplikacji, tenantów, integracji i urządzeń, a ostateczny termin potwierdza oferta.

Czy wykonujecie retest?

Tak. Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej.

Transport jest sektorem kluczowym, lecz zakres testu wynika z ryzyka

KSC obejmuje transport lotniczy, kolejowy, wodny i drogowy w zakresie określonym ustawą i kryteriami podmiotu. Pentest może dostarczyć dowodów skuteczności autoryzacji, bezpieczeństwa integracji i zarządzania podatnościami, ale nie należy utożsamiać go z całym audytem zgodności.

Źródła: Ministerstwo Cyfryzacji — sektory KSC, OWASP API Security i OWASP MASVS.