Interfejsy API stanowią szkielet nowoczesnych aplikacji i najczęściej atakowaną powierzchnię.Ponad 80% ruchu internetowego przepływa obecnie przez interfejsy API, a liczba ataków API wzrosła w ostatnich latach o 700%. Testowanie bezpieczeństwa API nie jest już opcjonalne — jest niezbędne dla każdej organizacji, która udostępnia interfejsy API partnerom, aplikacjom mobilnym lub Internetowi.
Kluczowe wnioski
- Interfejsy API mają unikalne luki:Lista 10 najważniejszych zabezpieczeń OWASP API obejmuje zagrożenia specyficzne dla interfejsów API, których nie zauważają tradycyjne testy sieciowe.
- Autoryzacja na poziomie uszkodzonego obiektu (BOLA) to ryzyko nr 1 API:Osoby atakujące manipulują identyfikatorami obiektów w żądaniach API, aby uzyskać dostęp do danych innych użytkowników.
- Luki w uwierzytelnianiu i ograniczaniu szybkości są wszechobecne:W wielu interfejsach API brakuje odpowiedniej walidacji tokena, ograniczania szybkości i zapobiegania nadużyciom.
- Wymagane jest testowanie automatyczne + ręczne:Zautomatyzowane skanery znajdują typowe wady API. Testowanie ręczne pozwala wykryć luki w logice biznesowej i złożone obejścia autoryzacji.
OWASP API Top 10 zabezpieczeń (2023)
| # | Luka w zabezpieczeniach | Opis | Podejście testowe |
|---|---|---|---|
| API1 | Autoryzacja na poziomie uszkodzonego obiektu | Dostęp do obiektów innych użytkowników poprzez zmianę identyfikatorów | Przetestuj każdy punkt końcowy za pomocą różnych tokenów użytkownika, wylicz identyfikatory obiektów |
| API2 | Złamane uwierzytelnienie | Słabe generowanie tokenów, brak walidacji, niepewne przepływy | Analiza tokenów, brutalna siła, manipulacja przepływem |
| API3 | Autoryzacja na poziomie właściwości uszkodzonego obiektu | Masowe przydzielanie, nadmierne ujawnianie danych w odpowiedziach | Dodawaj nieoczekiwane pola w żądaniach, analizuj dane odpowiedzi |
| API4 | Nieograniczone zużycie zasobów | Brak ograniczeń szybkości, paginacji lub rozmiaru | Testy powodziowe, testy dużych ładunków, obejście stronicowania |
| API5 | Uszkodzona autoryzacja poziomu funkcji | Dostęp do punktów końcowych administratora jako zwykły użytkownik | Przetestuj administracyjne punkty końcowe za pomocą tokenów innych niż administracyjne |
| API6 | Nieograniczony dostęp do wrażliwych przepływów biznesowych | Zautomatyzowane nadużywanie funkcjonalności biznesowych | Symulacja botów, automatyczne testowanie przepływu |
| API7 | Fałszowanie żądań po stronie serwera (SSRF) | API pobiera adresy URL kontrolowane przez atakującego | Manipulacja parametrami URL, sondowanie sieci wewnętrznej |
| API8 | Błędna konfiguracja zabezpieczeń | Rozwlekłe błędy, błędna konfiguracja CORS, niepotrzebne metody | Skanowanie konfiguracji, analiza nagłówków |
| API9 | Niewłaściwe zarządzanie zapasami | Przestarzałe, nieudokumentowane lub cieniste punkty końcowe API | API odkrycie, porównanie dokumentacji |
| API10 | Niebezpieczne korzystanie z interfejsów API | Ufanie odpowiedziom API stron trzecich bez sprawdzania | Manipulacja odpowiedziami, fałszowanie API |
API Metodologia testowania bezpieczeństwa
Odkrycie i przegląd dokumentacji
Zacznij od zmapowania wszystkich punktów końcowych API. Porównaj dokumentację API (specyfikacje OpenAPI/Swagger) z rzeczywistym zachowaniem. Użyj narzędzi takich jak Burp Suite, Postman i niestandardowych skryptów, aby wykryć nieudokumentowane punkty końcowe. Shadow API — punkty końcowe, które istnieją, ale nie są udokumentowane — są powszechne i często brakuje im kontroli bezpieczeństwa, ponieważ zostały zapomniane.
Testowanie uwierzytelniające
Przetestuj mechanizmy uwierzytelniania API: sprawdzanie poprawności tokenów JWT (czy można manipulować, fałszować lub odtwarzać tokeny tokenami?), przepływy OAuth (czy wymuszany jest parametr stanu? Czy można manipulować identyfikatorami URI przekierowań?), zarządzanie kluczami API (czy klucze mają odpowiedni zakres? Czy można je wyodrębnić z kodu po stronie klienta?) i zarządzanie sesją (czy tokeny wygasają? Czy można je unieważnić?).
Testy autoryzacyjne
Przetestuj każdy punkt końcowy z różnymi poziomami uprawnień. Zastąp identyfikatory użytkowników, identyfikatory dzierżawy i identyfikatory obiektów w żądaniach w celu sprawdzenia kontroli dostępu. Przetestuj autoryzację poziomą (użytkownik A uzyskujący dostęp do danych użytkownika B) i autoryzację pionową (zwykły użytkownik uzyskujący dostęp do punktów końcowych administratora). Korzystaj z automatyzacji, aby systematycznie testować wszystkie punkty końcowe — samo testowanie ręczne pomija punkty końcowe w dużych interfejsach API.
Walidacja danych wejściowych i testowanie wtrysku
Przetestuj wszystkie parametry wejściowe pod kątem podatności na iniekcję: iniekcja SQL w parametrach zapytania, iniekcja NoSQL w treściach JSON, iniekcja poleceń w punktach końcowych przetwarzania i iniekcja specyficzna dla GraphQL (zapytania zagnieżdżone, nadużycia introspekcji). Testuj zarówno ze zniekształconymi danymi wejściowymi (fuzzing), jak i starannie spreparowanymi ładunkami ukierunkowanymi na określone typy wtrysku.
API Narzędzia do testowania bezpieczeństwa
- Zestaw Burp:Kompleksowe testy bezpieczeństwa API z funkcjami proxy, skanera i automatyzacji.
- Listonosz:Platforma programistyczna API z kolekcjami testów bezpieczeństwa i automatycznymi skryptami testowymi.
- OWASP ZAP:Bezpłatny skaner bezpieczeństwa API z importem OpenAPI i automatycznym skanowaniem.
- Jądra:Skaner oparty na szablonach z szablonami specyficznymi dla API dla typowych luk w zabezpieczeniach.
- Ardżuna:Narzędzie do wykrywania parametrów HTTP umożliwiające wyszukiwanie ukrytych parametrów API.
- GraphQL Podróżnik:GraphQL API narzędzie do wizualizacji i introspekcji.
Jak Opsio testuje bezpieczeństwo API
- OWASP API Top 10 zasięgu:Każdy test API obejmuje wszystkie 10 kategorii z technikami testowania specyficznymi dla platformy.
- Podejście automatyczne + ręczne:Zautomatyzowane skanowanie w poszukiwaniu znanych luk, ręczne testowanie logiki biznesowej i złożonych błędów autoryzacyjnych.
- GraphQL wiedza specjalistyczna:Specjalistyczne testy interfejsów API GraphQL, w tym introspekcja, ataki zagnieżdżonymi zapytaniami i nadużycia zapytań wsadowych.
- Integracja CI/CD:Pomagamy zintegrować automatyczne testy bezpieczeństwa API z procesem wdrażania, aby zapewnić ciągłą pewność.
Często zadawane pytania
Czym różnią się testy bezpieczeństwa API od testowania aplikacji internetowych?
Testowanie aplikacji internetowych skupia się na interfejsie użytkownika i interakcjach zachodzących w przeglądarce. Testowanie API jest bezpośrednio ukierunkowane na warstwę API — testowanie punktów końcowych, parametrów, tokenów uwierzytelniających i serializacji danych, których interfejs użytkownika może nie ujawniać. Wiele luk istnieje tylko w warstwie API i nie można ich wykryć wyłącznie poprzez testowanie interfejsu użytkownika.
Czy powinienem testować wewnętrzne interfejsy API, czy tylko te dostępne publicznie?
Obydwa. Publiczne interfejsy API są bezpośrednio narażone na ataki atakujących i należy je najpierw przetestować. Wewnętrzne interfejsy API są często mniej zabezpieczone, ponieważ programiści zakładają ochronę na poziomie sieci. Jeśli osoba atakująca uzyska dostęp wewnętrzny (poprzez phishing, kompromis VPN lub błędną konfigurację chmury), wewnętrzne interfejsy API stają się powierzchnią ataku w przypadku ruchu bocznego i kradzieży danych.
Jak konkretnie zabezpieczyć interfejsy API GraphQL?
GraphQL wprowadza unikalne zagrożenia: nieograniczoną głębokość zapytań (odmowa usługi), ujawnienie introspekcji (wyciek schematu) i nadużycia zapytań wsadowych (omijanie limitów szybkości). Zabezpiecz GraphQL, wyłączając introspekcję w środowisku produkcyjnym, wdrażając limity głębokości i złożoności zapytań, wymuszając autoryzację dla poszczególnych pól i ograniczając szybkość na podstawie kosztu zapytania, a nie liczby żądań.