W API platformy do zarządzania flotą pojazdów dopisanie jednego pola do żądania aktualizującego profil zmieniało rolę użytkownika z kierowcy na administratora. Framework mapował wszystkie przesłane pola na kolumny w bazie, bo nikt nie określił, które z nich wolno modyfikować użytkownikowi. Naprawa polegała na wprowadzeniu obiektów transferu danych z jawną listą dozwolonych pól.
Schemat powyżej: Mass Assignment nie wymaga obchodzenia zabezpieczeń — wystarczy dopisać do żądania pole, o którym aplikacja nie miała powiedzieć, że istnieje.
- Endpoint aktualizacji profilu przyjmował dowolne pola i przekazywał je wprost do warstwy dostępu do bazy.
- Nazwę pola
roleodczytaliśmy z odpowiedzi tego samego API przy pobieraniu profilu. - Dopisanie
"role": "admin"do żądania podniosło uprawnienia konta. - Podatność nie wymagała żadnego exploita — tylko przeczytania własnych danych i jednej dodatkowej linijki w żądaniu.
Kontekst: „zaktualizuj swoje dane”
Aplikacja mobilna pozwalała kierowcom aktualizować dane kontaktowe: telefon i adres. API przyjmowało obiekt JSON i automatycznie mapowało jego pola na kolumny w bazie za pomocą frameworka ORM. Wygodne w programowaniu, ryzykowne w utrzymaniu.
Na czym polegał problem: mapowanie wszystkiego, co przyjdzie
Framework działał w konfiguracji domyślnej — akceptował każde przesłane pole, o ile odpowiadało kolumnie w modelu. Programiści nigdzie nie zdefiniowali, które pola wolno modyfikować użytkownikowi. Granica między „dane profilu” a „dane systemowe” istniała w dokumentacji, ale nie w kodzie.
Jak pracowaliśmy: odczytanie struktury z własnych danych
Analizując odpowiedzi API przy pobieraniu profilu, zobaczyliśmy pole role o wartości driver. Przy aktualizacji profilu wysłaliśmy standardowe żądanie, dopisując do niego to samo pole z wartością admin. Backend zaktualizował wszystkie przesłane pola, łącznie z rolą.
Nazwy pól nie trzeba było zgadywać — API samo je ujawniało w odpowiedzi. To częsty wzorzec: ten sam model służy do odczytu i do zapisu, więc wszystko, co widać przy pobieraniu, da się spróbować ustawić przy aktualizacji.
Ryzyko biznesowe: z kierowcy na dyrektora
Uprawnienia administratora dawały wgląd we wszystkie pojazdy, możliwość zmiany przypisania tras i usuwania kont innych użytkowników. W firmie transportowej to nie jest wyłącznie problem poufności danych — to ryzyko paraliżu operacyjnego.
Co zaleciliśmy i co wdrożono
- Obiekty transferu danych (DTO). Zamiast przekazywać surowy JSON do warstwy bazy, wprowadzono klasy definiujące wyłącznie pola dopuszczone do aktualizacji.
- Lista dozwolonych pól zamiast listy zakazanych. Wszystko, czego nie ma na liście, jest ignorowane — także pola dodane w przyszłości.
- Rozdzielenie modeli odczytu i zapisu w endpointach, w których to samo pole ma inny status przy pobieraniu i przy modyfikacji.
Efekt: aktualizuje się tylko to, co dozwolone
Po wdrożeniu próby przesłania pola role są po cichu ignorowane, a eskalacja uprawnień tą drogą stała się niemożliwa. Retest objął wszystkie endpointy modyfikujące dane, nie tylko profil użytkownika.
Jak zabezpieczyć się przed tym atakiem
Wszędzie tam, gdzie stosuje się automatyczne mapowanie danych na model, wymagaj listy dozwolonych pól. Najlepiej sprawdza się wzorzec obiektu transferu danych, który jednoznacznie określa akceptowaną strukturę wejścia i ignoruje wszystko poza nią.
Jeśli udostępniasz API aplikacjom mobilnym albo partnerom, warto sprawdzić to systemowo: takie podatności rzadko występują pojedynczo — zwykle dotyczą wszystkich endpointów zbudowanych tym samym wzorcem.
Powiązane case studies
- Niewidzialny podatek: luka BOLA w API fintechu — Brak kontroli uprawnień na poziomie obiektu w API — ten sam mechanizm, inny wektor.
- Jedno pole w GraphQL i nagle jesteś „innym klientem” — Podmiana identyfikatora w zapytaniu otwiera dane innego najemcy.
- Zakupy za grosze: Price Manipulation w checkoucie — Zaufanie do danych przesłanych przez klienta, tym razem w cenie zamówienia.
Jak Pentestica może pomóc
API bez warstwy graficznej nie ma niczego, co ograniczałoby dane wejściowe — każdy parametr trzeba sprawdzić osobno. Robimy to w ramach testów penetracyjnych, a szerszą ocenę architektury i uprawnień zapewnia audyt bezpieczeństwa IT.
Redakcja Pentestica to zespół pentesterów i konsultantów bezpieczeństwa, którzy na co dzień wykonują testy penetracyjne, testy TLPT wymagane przez DORA, red teaming i audyty bezpieczeństwa IT, a także prowadzą wdrożenia zgodności z NIS2, DORA i MiCA. Teksty na tym blogu piszemy z tej praktyki, a nie z opracowań. Każde twierdzenie o przepisie, terminie albo karze opieramy na źródle pierwotnym: dzienniku ustaw, tekście dyrektywy, komunikacie organu nadzoru. Jeśli czegoś nie da się potwierdzić, piszemy o tym wprost, zamiast powtarzać liczbę krążącą po branżowych portalach.