Śmierć przez tysiąc wycieków danych: jak interfejsy API przytłaczają bezpieczeństwo

Dzisiejsze powierzchnie ataków są szersze niż kiedykolwiek, a luki w zabezpieczeniach wydostają się z aplikacji i zasiedlają elastyczne interfejsy programowania aplikacji, które sprawiają, że świat technologii się zmienia.

Niestety, chociaż większość z nich zdaje sobie sprawę z zagrożeń związanych z tradycyjnymi aplikacjami internetowymi, interfejsy API pozostają niejasnym obszarem bezpieczeństwa. Dzisiejszy gargantuiczny krajobraz zagrożeń wymaga kompetentnego WAF w chmurze, a nawet inwestycji w WAAP.

Co to jest API?

Interfejsy API są spoiwem, które łączy nowoczesne środowisko przeglądania. Interfejsy API upraszczają użytkowanie i tworzenie oprogramowania, umożliwiając poszczególnym aplikacjom internetowym wymianę danych. Wysyłanie żądania do serwera za pośrednictwem aplikacji jest obecnie obsługiwane przez odpowiednie API, dzięki temu, że poprawnie zaimplementowane API są bardzo bezpieczne.

Zamiast bezpośredniego kontaktu serwera z Twoimi informacjami, Twoje urządzenie i odpowiedni interfejs API powinny udostępniać małe pakiety danych, przekazując tylko to, co jest konieczne.

Agile i API: podwójny problem z bezpieczeństwem

Agile to biznesowe hasło z przeszłości – opisuje formę produkcji, która wzmacnia przedsiębiorczą ideę „minimalnie opłacalnego produktu”. Celem Agile jest wypychanie minimalnego produktu na każdym etapie; zamiast nazywać produkt „skończonym”, jest po prostu zapętlony w kolejnej rundzie łatania, naprawiania błędów i ulepszeń.

Chociaż to ciągłe łatanie wydaje się fantastyczne dla bezpieczeństwa (stała obsługa oprogramowania? Fajnie!) Rzeczywistość ekonomiczna produkcji oprogramowania powoduje, że ilość interfejsów API szybko staje się niewygodna.

Ponieważ zespoły programistyczne działają szybko, interfejsy API rzadko są wyczerpująco dokumentowane. To sprawia, że ​​niezwykle trudno jest zajrzeć do wewnętrznych mechanizmów aplikacji i zrozumieć, które interfejsy API robią co. Sprawia to również, że bezpieczeństwo jest nieskończenie trudniejsze, ponieważ same zespoły programistyczne nie znają prawdziwej wielkości swoich zasobów API. To stawia cyberbezpieczeństwo na niskim priorytecie; zawsze reaktywny i nigdy proaktywny.

Przeoczone interfejsy API

Kiedy wspomina się o bezpieczeństwie aplikacji, pierwszą rzeczą, która przychodzi na myśl, są wagi ciężkie. Ataki, takie jak cross-site scripting; Wstrzyknięcie SQL i ataki DDoS są niezwykle dobrze znane. Same aplikacje są często dobrze strzeżone przez rozwiązania typu plug-and-play, takie jak zapory sieci Web Application Firewall.

Niewiele uwagi poświęca się API, ze szkodą dla nieświadomej organizacji i jej klientów. Weźmy za przykład lukę w interfejsie API, która pojawiła się w systemie Ubera.

Gdy kierowca Uber dołącza do Ubera za pośrednictwem linku polecającego, uruchamia aplikację i wprowadza kod polecający. Po naciśnięciu przycisku enter przeglądarka aplikacji komunikuje się z hostem API „bonjour.uber.com”. Stamtąd bonjour.uber otrzymuje parametr User ID i zwraca szczegóły dotyczące sterownika z powrotem do aplikacji użytkownika, gotowe do wprowadzenia na następującym ekranie akceptacji.

Jednak ten jeden interfejs API został uznany za winnego dwóch poważnych naruszeń bezpieczeństwa. Pierwszym z nich była autoryzacja na poziomie uszkodzonych obiektów (BOLA). Interfejs API nie sprawdził, czy identyfikator użytkownika pasuje do jego parametru identyfikatora; dzięki temu możliwy był dostęp do danych innych użytkowników poprzez prostą zmianę identyfikatora użytkownika.

Drugą kwestią była nadmierna ekspozycja danych. Odpowiedź API – aby zwrócić dane użytkownika – połączyła wszystkie te informacje w jedną partię, zawierającą wszystkie szczegóły użytkownika. Oznaczało to, że interfejs API zwrócił informacje, których klient wyraźnie nie potrzebował, naruszając główny filar najlepszych praktyk w zakresie cyberbezpieczeństwa.

Teraz weź pod uwagę, że przeciętna organizacja opiera się na ponad 15 500 API i zaczyna się pojawiać skala ryzyka. Na szczęście interfejs API Ubera został podłączony przed wystąpieniem jakichkolwiek poważnych uszkodzeń; następna firma nie miała tyle szczęścia.

Problem peletonu

Marka fitness w domu firmy Peloton cieszy się ponad 3 milionami abonentów. Zajęcia fitness na żywo są głównym punktem sprzedaży, ale jeśli nie chcesz udostępniać swoich danych medycznych innym uczestnikom zajęć, możesz ustawić swoje konto peletonowe jako prywatne.

Niestety, wiele luk w interfejsie API spowodowało ujawnienie tych danych nieautoryzowanym użytkownikom. Informacje o uczestnikach zajęć mogły zostać przeszukane na dużą skalę, ponieważ jeden punkt końcowy interfejsu API nie zweryfikował żądającego użytkownika. Umożliwiło to nieautoryzowanym atakującym uzyskanie nazwy użytkownika, lokalizacji, identyfikatora treningu, płci i wieku użytkowników Peloton.

Interfejsy API są od lat przyczyną głośnych wycieków danych. Ciągłe skandale danych Facebooka w latach 2018 i 2019 spowodowały, że dochodziło do naruszenia po drugim, głównie za pośrednictwem zewnętrznych interfejsów API dla programistów. Jednym z przykładów był Groups API; programiści pracujący nad aplikacją do zarządzania mediami społecznościowymi B2B mogli swobodnie uzyskiwać dostęp do imion i innych danych osobowych członków grupy. Chociaż ta aplikacja do zarządzania mediami społecznościowymi miała pomagać administratorom grup w bardziej efektywnym zarządzaniu grupami, Facebook musiał ją usunąć i jej interfejs API.

Te skandale z danymi zakończyły się w 2021 roku, kiedy z czarnorynkowej bazy danych ponad 533 milionów użytkowników Facebooka wyciekły ich nazwiska, numery telefonów i identyfikatory użytkowników Facebooka.

Zapobieganie wyciekom API

Open Web Application Security Project (OWASP) regularnie publikuje najpoważniejsze i najbardziej rozpowszechnione luki w zabezpieczeniach aplikacji internetowych, aby mieć na nie oko. Rosnące zagrożenie bezpieczeństwa reprezentowane przez interfejsy API jest wystarczająco poważne, aby zagwarantować własną listę OWASP z pierwszej dziesiątki, która jest stale na szczycie autoryzacji Broken Object Level Authorization.

Na szczęście ochrona interfejsów API — poza wymaganiem wolniejszego cyklu rozwoju — ściśle wiąże się z zabezpieczeniem całej organizacji jako całości. Pierwszym punktem połączenia będzie przyzwoita zapora aplikacji sieci Web (WAF). To rozwiązanie monitoruje granice Twoich aplikacji, zapobiegając wykorzystywaniu bram API przez główne luki w zabezpieczeniach.

Ochrona aplikacji internetowych i API (WAAP) idzie o krok dalej. Znajduje się całkowicie na granicy aplikacji dostępnej publicznie, analizując cały ruch przychodzący. Monitorując wzorce legalnego ruchu i żądań, WAAP są wysoce wyspecjalizowanymi narzędziami bezpieczeństwa zaprojektowanymi specjalnie do ochrony interfejsów API.

Podczas gdy WAAP jest systemem obronnym na poziomie punktu końcowego, rozwiązania Runtime Application Self Protection (RASP) obejmują określone aplikacje internetowe. Rozwiązanie RASP – w odróżnieniu od WAF – ma również wgląd w wewnętrzne działanie i zachowania związane z jego zastosowaniem. W ten sposób, jeśli interfejs API zostanie wykorzystany jako przyczółek w ataku i zostanie poproszony o więcej informacji, niż powinno być, RASP może proaktywnie zamknąć atak.

Dzięki niezliczonym opcjom ochrony interfejsu API zabezpieczenie aplikacji i organizacji nigdy nie było łatwiejsze.