Atakujący z dużym powodzeniem biorą na cel interfejsy API. Oto jak rozpocząć ocenę powierzchni ataku na API i zminimalizować ryzyko.
Żyjemy w świecie chmury obliczeniowej, urządzeń mobilnych i mikroserwisów. Prawie każda aplikacja, z którą wchodzimy w interakcję, jest zasilana przez API, często wiele, zwłaszcza gdy mamy do czynienia z wiodącymi dostawcami usług w chmurze (CSP), aplikacjami mobilnymi i środowiskami mikroserwisowymi. To sprawia, że interfejsy API stanowią krytyczną część powierzchni ataku organizacji. Akamai szacuje, że mniej więcej 83% ruchu internetowego jest oparte na API. Inne badania, takie jak te z Salt Security, stwierdzają, że ataki API wzrosły o ponad 600% w latach 2021-2022, a Gartner przewiduje, że 90% aplikacji internetowych będzie miało szersze powierzchnie ataku ze względu na odsłonięte API. Z najnowszego badania przeprowadzonego przez Imperva wynika, że podatne na ataki API kosztują organizacje od 40 do 70 miliardów dolarów rocznie.
Kolejną krytyczną częścią rozszerzającej się powierzchni ataku API jest przyjęcie Kubernetes i mikroserwisów. W jednym z badań znaleziono ostatnio ponad 380 000 narażonych na atak serwerów API Kubernetes, co jest niepokojące, biorąc pod uwagę, że serwer API Kubernetes jest podstawowym komponentem płaszczyzny kontrolnej we wdrożeniach kontenerowych. Mimo to, bardzo mało uwagi poświęca się bezpieczeństwu API, mimo że w rzeczywistości interfejsy API pełnią rolę kleju zasilającego nowoczesny ekosystem cyfrowy.
Zobacz również:
Interfejsy API są wykorzystywane do uzyskiwania dostępu do danych i ich wyszukiwania, a także do wykonywania takich czynności jak wzbogacanie i modyfikowanie danych w ramach procesów. Oznacza to, że same interfejsy API muszą być zabezpieczone, podobnie jak przepływające przez nie dane.
Ta rzeczywistość podkreśla potrzebę stosowania najlepszych praktyk w zakresie bezpieczeństwa aplikacji i danych podczas pracy z interfejsami API. Podobnie jak w przypadku wielu innych obszarów technologii, większość organizacji boryka się z prostym zadaniem przeprowadzenia inwentaryzacji swoich interfejsów API. Oznacza to, że większość z nich nie ma wglądu w to, jakie interfejsy API posiadają, z jakimi wchodzą w interakcje i jakie są istotne dla ich powierzchni ataku.
Organizacje takie jak Resurface Labs i Traceable AI zaczęły zajmować się tym problemem, ale trzeba wykonać jeszcze wiele pracy. Oto gdzie organizacje powinny zacząć rozumieć swoją powierzchnię ataku API i jej potencjalne podatności.
Jak rozpocząć ocenę rozmiaru powierzchni ataku API
Bezpieczeństwo interfejsów API może być trudnym zadaniem dla organizacji, które dopiero zaczynają, zwłaszcza dla dużych przedsiębiorstw z rozległymi zasobami interfejsów API. Mimo to można zastosować rozsądne praktyki i metodologie, aby poradzić sobie z tym w dużej mierze nieuwzględnionym wektorem ataku. Podejście to wymaga połączenia zarządzania, bezpieczeństwa infrastruktury i najlepszych praktyk na poziomie aplikacji w celu zmniejszenia ryzyka organizacyjnego.
Świetnym miejscem do rozpoczęcia, oprócz inwentaryzacji istniejących organizacyjnych interfejsów API, jest zidentyfikowanie i zrozumienie najczęstszych problemów związanych z bezpieczeństwem API. Na szczęście, zawsze wartościowa społeczność OWASP stworzyła listę 10 najlepszych zabezpieczeń API. Obejmuje ona takie elementy, jak złamana autoryzacja obiektu i użytkownika/uwierzytelnianie, nadmierna ekspozycja danych i brak ograniczenia tempa.
Złamana autoryzacja na poziomie obiektu jest konstrukcją na poziomie kodu, która zapewnia użytkownikom dostęp tylko do obiektów, do których są upoważnieni. Wiąże się to z wszechobecną koncepcją kontroli dostępu dla najmniej uprzywilejowanych, która jest również powszechna w dążeniu do modelu Zero Trust.
Uszkodzone uwierzytelnianie użytkowników przejawia się w różnych formach, w tym w słabych mechanizmach uwierzytelniania, obecności wrażliwych informacji o uwierzytelnianiu w adresach URL oraz w credential stuffing, gdzie złośliwi aktorzy używali uzyskanych informacji o uwierzytelnianiu do wielokrotnych prób wykorzystania interfejsów uwierzytelniania. Rozwiązanie tych podatności wymaga zrozumienia przepływów uwierzytelniania, mechanizmów i stosowania branżowych standardów uwierzytelniania.
Nadmierna ekspozycja danych to problem aż nazbyt powszechny. W przypadku interfejsów API, podatność ta pojawia się zazwyczaj, gdy interfejs API zwraca wrażliwe dane w odpowiedzi na działania użytkownika, których nie powinien ujawniać. Organizacje mogą zaradzić tym podatnościom poprzez weryfikację danych zawartych w odpowiedziach API i upewnienie się, że dane wrażliwe nie zostały przypadkowo zawarte. Organizacje powinny również wdrożyć mechanizmy walidacji odpowiedzi, aby upewnić się, że wrażliwe dane nie są narażone.
Brak kontroli ograniczających szybkość działania jest raczej związany z wpływem na dostępność systemów niż z naruszeniem poufności lub integralności, jak to miało miejsce w przypadku innych wiodących, powszechnie występujących podatności. Biorąc pod uwagę, że interfejsy API często funkcjonują jako klej, który łączy nowoczesne mikroserwisy, chmury i aplikacje mobilne, wszystkie używane do ostatecznego dostarczania wartości klientom i napędzania przychodów, wpływ na dostępność jest istotnym problemem. Przerwa w działalności może oznaczać utratę przychodów lub zaufania klientów. Jeśli działasz w sektorze publicznym lub bezpieczeństwa narodowego, może to mieć wpływ na krytyczne usługi obywatelskie i bezpieczeństwo narodowe.
Problemy te mogą wydawać się oczywiste dla doświadczonego praktyka bezpieczeństwa, biorąc pod uwagę, że uwierzytelnianie, autoryzacja i ataki DoS (Denial of Service) są powszechne. Jeśli jednak weźmiemy pod uwagę niektóre z wcześniejszych danych dotyczących rozpowszechnienia interfejsów API w organizacjach i Internecie, w połączeniu z szybko rosnącym wskaźnikiem ataków na interfejsy API ze strony złośliwych podmiotów, potencjalne ryzyko staje się jeszcze większe.
Interfejsy API umożliwiają przemieszczanie się na boki
Biorąc pod uwagę, że interfejsy API często służą jako drzwi wejściowe do aplikacji i środowisk cyfrowych, ataki na nie są często wykorzystywane do przemieszczania się w poprzek systemów. Interfejsy API mogą stanowić początkowy wektor ataku, a następnie zostać wykorzystane do uzyskania dostępu do systemów bazowych, obciążeń i danych. To sprawia, że zabezpieczenie ich jest niezwykle ważne. Podstawowe wektory ataku na interfejsy API obejmują uwierzytelnianie i autoryzację na poziomie obiektu i użytkownika. Złośliwym aktorom nie chodzi więc o same interfejsy API, ale o dane, do których mają dostęp i które transportują, a także o systemy bazowe, przed którymi często siedzą.
Większy nacisk na bezpieczeństwo API
Choć wiele z tych wektorów ataku może nie wydawać się wyjątkowych dla interfejsów API, stają się one bardzo niepokojące, gdy połączy się je z wszechobecnością interfejsów API w nowoczesnym ekosystemie cyfrowym. Na szczęście pojawia się kilka trendów, w tym zwiększone inwestycje w startupy i produkty związane z bezpieczeństwem API, więcej wskazówek dotyczących bezpieczeństwa API oraz zwiększona świadomość branży, jak problematyczne mogą być niezabezpieczone interfejsy API.
Jeśli interfejsy API stały się więzami łączącymi nowoczesny ekosystem cyfrowy, to jako branża musimy zapewnić, że te więzy są solidne i nie mamy ekosystemu związanego gumą balonową i sznurówkami. Podczas gdy starszy model zabezpieczeń opartych na obwodach mógł odejść do lamusa, interfejsy API nadal służą jako krytyczny punkt wejścia i obrotu dla nowoczesnych systemów. Dotyczy to nie tylko systemów skierowanych na zewnątrz, ale także systemów komunikujących się wewnętrznie.
Obserwujemy również wysiłki mające na celu zabezpieczenie łańcucha dostaw oprogramowania. Łańcuch ten jest połączony za pomocą interfejsów API, które stanowią podstawową metodę komunikacji między systemami opartymi na oprogramowaniu. Wskazuje to na bezpieczeństwo API jako kluczowy element szerszego ekosystemu łańcucha dostaw oprogramowania, który również wymaga bezpieczeństwa i rygoru.
Źródło: CSO
Zgłoś naruszenie/Błąd
Oryginalne źródło ZOBACZ
Dodaj kanał RSS
Musisz być zalogowanym aby zaproponować nowy kanal RSS