Czasem odrywam się od zajęć związanych z analizą podatności, pisaniem kodu, dokumentacji czy wymagań i lubię wczytać się w raporty publikowane przez niektóre organizacje – aby trzymać ręce na pulsie i dbać o to aby wiedza o zagrożeniach, o których staram się uświadamiać programistów była aktualna ;). I w ten sposób wpadł mi przed oczy raport opublikowany Imperve na temat tego jak wygląda bezpieczeństwo API w 2024 roku.
Z uwagi na to, że raport ma aż 26 stron (sic!) stwierdziłem, że podzielę się z Wami skrótem i podsumowaniem.
Według autorów dokumentu obecnie ruch API w przestrzeni Internetu stanowi ponad 71% całego ruchu, co związane jest z modernizacjami aplikacji i architektury i “przechodzeniu” na model “API First”. Jednakże, to powszechne użycie rozszerza potencjalne wektory ataku wprowadzając liczne wyzwania bezpieczeństwa takie jak `Shadow API`, wykorzystanie API tzw. 3rd party, zarządzanie cyklem życia API, błędy w logice biznesowej, wycieki danych czy wyraźny brak umiejetności w zakresie projektowania API przez architektów. Kluczowe zagrożenia, które zostały zasygnalizowane związane są z brakiem kompleksowej widoczności ekosystemów API (rozproszone informacje o tym gdzie jaki endpoint jest zrealizowany czy jak zbudowany), zwiększona aktywność zautomatyzowanych ataków, które exploitują logikę biznesową, nadużycia botów (zwiększających ruch i próbujących wstrzykiwać śmieciowe informacje) oraz nieefektywne sposoby zabezpieczania i ochrony przed zagrożeniami.
Ataki na logikę biznesową
W 2023 roku, nadużycie logiki biznesowej (Business Logic Abuse) zostało wskazane jako główny wektor ataku, zauważono wzrost o 10% w porównaniu do poprzedniego roku, osiągając poziom 27% wszystkich ataków na API. To nadużycie polega na wykorzystywaniu zamierzonej funkcjonalności API w złych celach, takich jak wykradanie danych. Znacznie utrudnia to wykrywanie i łagodzenie zagrożeń przez tradycyjne narzędzia bezpieczeństwa, ponieważ ataki te często maskują się jako normalny ruch. Przykłady takich ataków obejmują tworzenie fałszywych kont czy scraping danych, co prowadzi do strat finansowych i uszczerbku na reputacji firm.
Shadow APIs i Związane z Nimi Ryzyko
Shadow API, nazywane również jako niedokumentowane API lub nieodkryte API, to API działające poza oficjalnymi i monitorowanymi kanałami w organizacji. Takie API mogą być tworzone planowo przez programistów, którzy dążą do przyspieszenia swojej pracy, lub mogą być pozostałością po poprzednich wersjach oprogramowania. Chociaż Shadow APIs mogą mieć praktyczne zastosowania, takie jak testowanie nowych funkcji lub ułatwianie operacji wewnętrznych, ich istnienie stanowi znaczące ryzyko bezpieczeństwa dla organizacji. Jeśli zostaną zmanipulowane i wykorzystane, mogą narazić na szwank wrażliwe dane, potencjalnie prowadząc do naruszeń bezpieczeństwa i niezgodności z przepisami.
Automatyczne Ataki i Aktywność Botów
Automatyczne ataki, szczególnie te wykorzystujące złośliwe boty, stanowiły znaczący odsetek nadużyć API. Raport wskazuje, że w miejscach klientów z istotną aktywnością API, ponad 56% ruchu internetowego można przypisać działalności botów. Podkreśla to kluczową rolę zaawansowanej ochrony przed botami w strategiach bezpieczeństwa API. Ataki automatyczne, takie jak wypełnianie danych kredytowych (credential stuffing) czy automatyczne tworzenie kont, wykorzystują API do realizacji złośliwych działań, co utrudnia ich wykrycie przez tradycyjne narzędzia bezpieczeństwa i podkreśla potrzebę lepszej widoczności infrastruktury API.
Niewystarczająca ochrona API
Raport podkreśla, że tradycyjne środki bezpieczeństwa, takie jak firewalle aplikacyjne (WAF) i ochrona przed DDoS, choć ważne, są niewystarczające wobec specyficznych zagrożeń dla API. Nowoczesne ataki, takie jak te wykorzystujące nadużycia logiki biznesowej, często omijają tradycyjne zabezpieczenia, ponieważ te nie są dostosowane do specyfiki i złożoności interakcji API. W efekcie, potrzebne są bardziej zaawansowane rozwiązania bezpieczeństwa API, które mogą rozpoznać i przeciwdziałać unikatowym wektorom ataku, takim jak te wymienione w OWASP API Security Top 10.
Podsumowanie
Ciężko dyskutować o liczbach przedstawionych w raporcie z uwagi na brak opisanej metodologi czy wielkości próbki – nie to jest jednak najważniejsze. Bezpieczeństwo API w 2024 jest bardzo istotne. Wnioski, które zostały sformułowane z mojej perspektywy są bardzo trafne.
Bardzo ważne jest aby twórcy, architekci i testerzy mieli świadomość zagrożeń, które płyną ze wskazanych źródeł: aktywność botów oraz automatyzowane ataki na API.
Jednak z mojej perspektywy najważniejszy jest punkt dotyczący braku widoczności i dokumentowania API w organizacjach. Czy jesteś w prosty sposób w stanie powiedzieć jakie dane w jakim formacie są akceptowane w konkretnym endpoint’cie rozwijanego przez siebie API? Tego typu wiedza jest bardzo istotna aby docelowo zaimplementować w poprawny sposób weryfikacje danych wejściowych do aplikacji o czym mówię na szkoleniu security by design: bezpieczeństwo kodu źródłowego (choć nie wspominam stricte o API – zasady są bardzo podobne).https://academy.mixeway.io/p/security-by-design-bezpieczenstwo-aplikacji-i-kodu-zrodlowego
Moja rada i sugestia do wszystkich autorów i architektów API: utrzymujcie i aktywnie rozwijajcie opis budowanego rozwiązania – istnieją bardzo fajne i przyjazne formaty opisu API REST w formie OpenAPI Specification (a.k.a swagger). Ba, większość popularnych frameworków potrafi takie opisy generować automatycznie na podstawie konfiguracji kontrolerów, wykrytych w kodzie.