Niezabezpieczone korzystanie z interfejsu API

Kategoria OWASP: MASVS-PLATFORM: Platform Interaction

Omówienie

Wiele aplikacji mobilnych korzysta z zewnętrznego interfejsu API, aby udostępniać funkcje. Tradycyjnie do uwierzytelniania aplikacji łączącej się z usługą używa się statycznego tokena lub klucza.

Jednak w kontekście ustawień klient-serwer (lub aplikacji mobilnej i interfejsu API) używanie statycznego klucza nie jest ogólnie uważane za bezpieczną metodę uwierzytelniania dostępu do danych lub usług wrażliwych. W przeciwieństwie do infrastruktury wewnętrznej każdy może uzyskać dostęp do zewnętrznego interfejsu API i nadużywać usługi, jeśli ma dostęp do tego klucza.

Na przykład klucz statyczny może zostać odtworzony na podstawie aplikacji lub przechwycony, gdy aplikacja mobilna komunikuje się z zewnętrznym interfejsem API. Jest też bardziej prawdopodobne, że ten statyczny klucz będzie zakodowany na stałe w aplikacji.

Ryzyko związane z danymi i usługami interfejsu API występuje, gdy nie są stosowane wystarczająco bezpieczne mechanizmy uwierzytelniania i kontroli dostępu.

W przypadku używania klucza statycznego interfejs API może zostać wykorzystany przez odtwarzanie żądań lub tworzenie nowych żądań za pomocą klucza (przechwyconego lub odtworzonego metodą inżynierii wstecznej) bez żadnych ograniczeń czasowych.

Wpływ

Jeśli deweloper płaci za usługę interfejsu API AI lub ML, atakujący może stosunkowo łatwo ukraść ten klucz i narazić dewelopera na długi lub wykorzystać go do tworzenia fałszywych treści.

Wszelkie dane użytkownika, pliki lub informacje umożliwiające identyfikację przechowywane w interfejsie API byłyby swobodnie dostępne, co prowadziłoby do szkodliwych wycieków.

Atakujący może też wykorzystać ten dostęp do oszustw, przekierowywania usług, a w rzadkich przypadkach do przejęcia pełnej kontroli nad serwerami.

Środki ograniczające ryzyko

Interfejs API z zachowywaniem stanu

Jeśli aplikacja umożliwia logowanie użytkowników lub śledzenie sesji użytkowników, zalecamy deweloperom korzystanie z usługi API, takiej jak Google Cloud, w celu integracji z aplikacją z zachowaniem stanu.

Dodatkowo korzystaj z bezpiecznego uwierzytelniania, weryfikacji klienta i kontroli sesji udostępnianych przez usługę API oraz rozważ użycie tokena dynamicznego jako alternatywy dla klucza statycznego. Sprawdź, czy token wygasa w stosunkowo krótkim czasie (zwykle jest to 1 godzina).

Token dynamiczny powinien być następnie używany do uwierzytelniania, aby zapewnić dostęp do interfejsu API. Te wskazówki pokazują, jak to zrobić za pomocą OAuth 2.0. Oprócz tych wytycznych protokół OAuth 2.0 można dodatkowo wzmocnić, aby zmniejszyć podatność aplikacji na Androida na ataki, wdrażając te funkcje:

Zastosuj odpowiednią obsługę błędów i logowanie:

  • Obsługuj błędy OAuth w sposób prawidłowy i widoczny oraz rejestruj je na potrzeby debugowania.
    • Zmniejszona powierzchnia ataku pomoże Ci też identyfikować i rozwiązywać wszelkie problemy, które mogą się pojawić.
    • Zadbaj o to, aby wszystkie wiadomości rejestrowane lub wyświetlane użytkownikowi były jasne, ale nie zawierały informacji przydatnych dla przeciwnika.

Bezpiecznie skonfiguruj OAuth w aplikacji:

  • Wyślij parametr redirect_uri do punktów końcowych autoryzacji i tokena.
  • Jeśli Twoja aplikacja korzysta z OAuth w przypadku usługi innej firmy, skonfiguruj współdzielenie zasobów pomiędzy serwerami z różnych domen (CORS), aby ograniczyć dostęp do zasobów aplikacji.
    • Pomoże to zapobiegać nieautoryzowanym atakom typu cross-site scripting (XSS).
  • Aby zapobiegać atakom typu CSRF, używaj parametru state.

Użyj biblioteki zabezpieczeń:

  • Aby uprościć wdrażanie bezpiecznych przepływów OAuth, rozważ użycie biblioteki zabezpieczeń, takiej jak AppAuth.
    • Te biblioteki Androida mogą pomóc w automatyzacji wielu wspomnianych wcześniej sprawdzonych metod w zakresie bezpieczeństwa.

Inne metody uwierzytelniania, w tym tokeny Firebase i tokeny identyfikatora Google, są opisane w dokumentacji OpenAPI.

Interfejs API bezstanowy

Jeśli usługa API nie oferuje żadnej z zalecanych wcześniej form ochrony i wymagane są sesje bezstanowe bez logowania użytkownika, deweloperzy mogą potrzebować własnych rozwiązań pośredniczących.

Obejmowałoby to „przekazywanie” żądań między aplikacją a punktem końcowym interfejsu API. Jednym ze sposobów jest użycie tokenów sieciowych JSON (JWT) i podpisu sieciowego JSON (JWS) lub udostępnienie w pełni uwierzytelnionej usługi, jak zalecaliśmy wcześniej. Umożliwia to przechowywanie podatnego na ataki klucza statycznego po stronie serwera, a nie w aplikacji (kliencie).

W przypadku aplikacji mobilnych istnieją nieodłączne problemy z zapewnieniem kompleksowego rozwiązania bezstanowego. Do najważniejszych wyzwań należy weryfikacja klienta (aplikacji) i bezpieczne przechowywanie klucza prywatnego lub tajnego na urządzeniu.

Interfejs Play Integrity API weryfikuje integralność aplikacji i żądań. Może to ograniczyć niektóre sytuacje, w których dostęp ten może być nadużywany. Jeśli chodzi o zarządzanie kluczami, w wielu przypadkach magazyn kluczy jest najlepszym miejscem do bezpiecznego przechowywania kluczy prywatnych.

Niektóre aplikacje mobilne używają fazy rejestracji do sprawdzania integralności aplikacji i udostępniania klucza za pomocą bezpiecznej wymiany. Te metody są złożone i wykraczają poza zakres tego dokumentu. Jednak usługa zarządzania kluczami w chmurze może być jednym z rozwiązań.

Materiały