Bezpieczeństwo API - OWASP API Security Top 10 w praktyce

W skrócie: API nie chowa błędów za przyciskiem w interfejsie - punkty końcowe są przewidywalne, a struktura odpowiedzi sama podpowiada, o co jeszcze można poprosić. OWASP API Security Top 10 2023 to osobna lista od klasycznego OWASP Top 10 dla aplikacji webowych - pierwsza pozycja to Broken Object Level Authorization (BOLA), czyli dostęp do cudzych danych przez samą zmianę identyfikatora w żądaniu.

To najczęstsza i zarazem najprostsza do wykorzystania podatność w API - nie wymaga narzędzi, tylko dwóch kont i podmiany liczby w adresie URL.

W poprzednim wpisie o OWASP Top 10 omawialiśmy listę dla klasycznych aplikacji webowych. API ma własną, osobną listę - i choć obie dotyczą bezpieczeństwa warstwy aplikacyjnej, rozkład ryzyka jest inny. W aplikacji z interfejsem błąd autoryzacji bywa trudny do zauważenia, bo nikt nie widzi przycisku prowadzącego do cudzych danych. W API struktura jest jawna - punkty końcowe mają przewidywalne nazwy, a odpowiedzi ujawniają kształt danych, który sam podpowiada kolejne zapytanie.

Dziesięć kategorii OWASP API Security Top 10:2023

Kategoria	Na czym polega
API1 Broken Object Level Authorization	Serwer sprawdza, że użytkownik jest zalogowany, ale nie sprawdza, czy konkretny zasób należy do niego
API2 Broken Authentication	Błędy w mechanizmach uwierzytelniania pozwalają przejąć tokeny albo obejść logowanie
API3 Broken Object Property Level Authorization	Łączy nadmierną ekspozycję danych i mass assignment - brak kontroli na poziomie pojedynczych pól obiektu, nie tylko całego zasobu
API4 Unrestricted Resource Consumption	Brak limitów na zużycie pasma, CPU, pamięci i miejsca na dysk przy obsłudze żądań
API5 Broken Function Level Authorization	Złożone hierarchie ról i grup prowadzą do błędów, które pozwalają wywołać funkcje administracyjne z konta zwykłego użytkownika
API6 Unrestricted Access to Sensitive Business Flows	Funkcja biznesowa dostępna bez ograniczeń na to, jak bardzo można ją wykorzystać (np. automatyczne wykupywanie puli produktów)
API7 Server Side Request Forgery	API pobiera zasób spod adresu URL podanego przez użytkownika bez jego walidacji
API8 Security Misconfiguration	Złożona konfiguracja API i infrastruktury wokół niego, w której łatwo pominąć dobrą praktykę
API9 Improper Inventory Management	API ma zwykle więcej punktów końcowych niż aplikacja webowa, a dokumentacja i tak nie nadąża za zmianami
API10 Unsafe Consumption of APIs	Deweloperzy ufają danym z zewnętrznych API bardziej niż danym od użytkownika, więc stosują wobec nich słabsze zabezpieczenia

Dlaczego BOLA jest na pierwszym miejscu

Żądanie o zasób numer 1042 działa poprawnie. Żądanie o zasób numer 1041 zwraca cudze dane. To cały atak - żadnego narzędzia poza przeglądarką albo Burp Suite, żadnej wiedzy o wewnętrznej architekturze systemu, tylko systematyczne przejście przez zakres identyfikatorów na dwóch kontach testowych. Właśnie dlatego BOLA zajmuje pierwszą pozycję: niska bariera wejścia przy wysokiej skuteczności. Wykrycie wymaga dyscypliny - przejścia przez każdy punkt końcowy, który przyjmuje identyfikator, z dwóch różnych kont - ale sam atak, gdy podatność istnieje, jest trywialny.

Rodzina błędów wynikających z zaufania do klienta

API3 łączy dwa zjawiska, które do 2019 roku były osobnymi kategoriami: nadmierną ekspozycję danych i mass assignment. Oba wynikają z tego samego źródła - serwer ufa, że klient (aplikacja frontendowa, aplikacja mobilna) sam zadba o to, które pola pokazać, a które przyjąć. Odpowiedź API zawiera więc komplet pól z bazy danych, nawet jeśli interfejs wyświetla tylko część z nich - reszta i tak trafia w treści odpowiedzi, czytelna dla każdego, kto podejrzy ruch sieciowy. Mass assignment działa w drugą stronę: serwer przyjmuje pole, którego żaden formularz nie wysyła, na przykład rolę użytkownika albo status weryfikacji, bo nie sprawdza, czy to pole powinno być w ogóle edytowalne przez tego nadawcę.

Czym to się różni od testów aplikacji webowej

OWASP Top 10 dla aplikacji webowych skupia się na szerszym spektrum - od iniekcji, przez błędy kryptograficzne, po podatności w komponentach. Lista API jest węższa, ale głębsza w jednym konkretnym obszarze: autoryzacji. Aż trzy z dziesięciu kategorii (API1, API3, API5) dotyczą wprost błędów kontroli dostępu na różnych poziomach - obiektu, pojedynczej właściwości obiektu i funkcji. To nie przypadek. API z natury eksponuje więcej punktów decyzyjnych niż aplikacja z interfejsem, bo każdy punkt końcowy to osobna okazja do pominięcia sprawdzenia uprawnień. Tam, gdzie w aplikacji webowej jeden ekran agreguje wiele operacji za jedną kontrolą dostępu, w API każda z tych operacji to osobne żądanie, które trzeba zabezpieczyć z osobna.

GraphQL wymaga innego podejścia

REST i GraphQL mają różną powierzchnię ataku. W GraphQL dochodzi ryzyko introspekcji (ujawnienie całego schematu zapytań bez dokumentacji), zagnieżdżania zapytań prowadzącego do nadmiernego zużycia zasobów (pokrewne API4), autoryzacji na poziomie pojedynczych pól zamiast całych typów, oraz możliwości obejścia limitów żądań przez aliasy - jedno żądanie HTTP może zawierać dziesiątki aliasowanych zapytań, z których każde liczy się osobno dla serwera, ale nie zawsze osobno dla prostego licznika żądań.

Co sprawdzamy w teście

Przy testach penetracyjnych API weryfikujemy kompletną listę OWASP API Security Top 10, w praktyce skupiając się na kilku powtarzających się wzorcach:

Systematyczne testy BOLA na każdym punkcie końcowym przyjmującym identyfikator, z dwóch kont o różnych uprawnieniach.
Wywołanie funkcji administracyjnych z konta zwykłego użytkownika - punkty końcowe nieukryte w interfejsie, ale dostępne bezpośrednio pod adresem.
Porównanie pól w odpowiedzi API z polami widocznymi w interfejsie - szukanie nadmiarowych danych, które serwer wysyła, a frontend po prostu nie wyświetla.
Próby mass assignment - dopisanie pola spoza oczekiwanego formularza (rola, status, flaga uprawnień) i sprawdzenie reakcji serwera.
Testy limitów żądań przy logowaniu, resecie hasła i operacjach kosztownych obliczeniowo.
Dla GraphQL: stan introspekcji, głębokość zagnieżdżania zapytań i autoryzacja na poziomie pól.

Co robić

Sprawdzaj własność zasobu przy każdym żądaniu, nie tylko to, czy użytkownik jest zalogowany.
Definiuj jawnie, które pola są zwracane i które przyjmowane - zamiast serializować cały obiekt z bazy wprost do odpowiedzi.
Egzekwuj autoryzację na poziomie funkcji po stronie serwera, nie polegaj na tym, że interfejs nie pokazuje danej opcji zwykłemu użytkownikowi.
Limituj żądania per użytkownik i per punkt końcowy, szczególnie przy operacjach uwierzytelniających i kosztownych.
Prowadź aktualny rejestr punktów końcowych. Dokumentacja OpenAPI, która nadąża za zmianami, to też zabezpieczenie - nieudokumentowany punkt końcowy to taki, o którym nikt nie pamięta, żeby go zabezpieczyć.

Czego to nie załatwi

Skaner automatyczny wykryje część błędów konfiguracji i oczywiste braki zabezpieczeń, ale błędów autoryzacji na poziomie obiektu praktycznie nie da się wykryć bez manualnego porównania dwóch kont - automatyczne narzędzie nie wie, które dane należą do kogo. To dokładnie ten rodzaj testu, który wymaga człowieka systematycznie przechodzącego przez punkty końcowe z dwóch różnych perspektyw, nie jednego skanu uruchomionego raz na kwartał.