Każdy pull request Dodanie lub zmiana punktu końcowego zmienia powierzchnię ataku API. Większość narzędzi do zabezpieczania API nie zauważa tego, dopóki punkt końcowy nie będzie aktywny i nie będzie już obsługiwał ruchu. Wtedy poprawka nie ogranicza się już do zmiany jednego wiersza kodu w przeglądzie, ale do rozmowy w ramach reagowania na incydenty.
Bezpieczeństwo interfejsu API polega na wyszukiwaniu i eliminowaniu zagrożeń związanych ze sposobem, w jaki aplikacja ujawnia swoje punkty końcowe: kto może je wywołać, jakie dane zwracają i czy robią to, co opisuje dokumentacja.
Większość narzędzi stworzonych do rozwiązania tego problemu testuje API w czasie wykonywania, z zewnątrz, w taki sam sposób, jak zrobiłby to atakujący. To podejście działa, ale dopiero po wdrożeniu API. Xygeni wybiera wcześniejszą ścieżkę: odczytuje kod źródłowy i specyfikację API zanim jakiekolwiek żądanie dotrze do punktu końcowego.
Cztery sposoby testowania API i odpowiedzi na każde z nich
Większość dojrzałych programów obsługuje więcej niż jeden z poniższych sposobów:
- Testy statyczne Analizuje kod źródłowy i specyfikacje API przed wdrożeniem. Odpowiada na pytanie „co właśnie ujawniliśmy?”. Na tym podejściu skupia się ten artykuł.
- Testowanie dynamiczne (DAST) Wysyła rzeczywisty ruch do działającego API i obserwuje jego reakcję. Odpowiada na pytanie „co jest aktualnie osiągalne i podatne na atak?”.
- Nieostre generuje nieprawidłowe lub nieoczekiwane dane wejściowe w punktach końcowych, powodując awarie powierzchniowe i błędy w skrajnych przypadkach. Odpowiada na pytanie „co psuje się pod wpływem danych wejściowych, których się nie spodziewaliśmy?”
- Ręczne testy penetracyjne Dodaje ludzki osąd, aby znaleźć błędy logiczne, których nie dostrzegają zautomatyzowane narzędzia. Odpowiada na pytanie „co inteligentny atakujący połączyłby w łańcuch?”.
Żadne z nich nie zastępuje pozostałych. Odpowiadają na różne pytania na różnych etapach cyklu życia, a luka, którą ma większość programów, to ta pierwsza.
Dlaczego większość narzędzi zabezpieczających API zbyt późno dostrzega ryzyko
Testowanie bezpieczeństwa API w czasie wykonywania (Runtime) wysyła ruch do działającej aplikacji i obserwuje jej reakcję. To prawidłowa i niezbędna warstwa. Z założenia jest to również wskaźnik opóźnień: punkt końcowy musi istnieć, zostać wdrożony i być osiągalny, zanim skaner w czasie wykonywania będzie mógł cokolwiek o nim powiedzieć. Cokolwiek znajdzie, było już wykryte przez czas trwania skanowania.
Pod tym problemem czasowym kryje się druga luka. Narzędzia uruchomieniowe mogą testować tylko to, co wiedzą, że istnieje. Jeśli punkt końcowy nigdy nie został udokumentowany lub specyfikacja OpenAPI stała się nieaktualna w momencie wysłania nowej trasy, skaner uruchomieniowy nie ma możliwości wykrycia jego obecności. Testuje mapę, a nie terytorium.
Statyczne testowanie bezpieczeństwa API niweluje obie luki, przenosząc kontrolę do miejsca, w którym zdefiniowany jest punkt końcowy: kodu i specyfikacji API, przed wdrożeniem. pull request który wprowadza punkt końcowy to pull request co ujawnia jego ryzyko.
Co tak naprawdę oznacza bezpieczeństwo statycznego interfejsu API
Xygeni tworzy Twój inwentarz API na podstawie dwóch źródeł: kodu źródłowego Twojej aplikacji i specyfikacji API, obejmujących OpenAPI i Swagger.
Inwentaryzacja oparta wyłącznie na specyfikacji pokazuje punkty końcowe, o których udokumentowaniu ktoś pamiętał. Inwentaryzacja oparta wyłącznie na kodzie pokazuje, co istnieje, ale niekoniecznie, jak miało być używane. Zapoznanie się z obiema metodami daje pełny obraz: punkty końcowe udokumentowane przez zespoły i te, których nikt nie udokumentował.
Ten inwentarz stanowi fundament, na którym budujemy wszystko inne:
- Łączna liczba odkrytych interfejsów API i zagrożonych zasobów mierzona w stosunku do wartości bazowej
- Punkty końcowe podzielone według metody HTTP
- Problemy pogrupowane według usługi
- Każdy punkt końcowy ze swoją metodą, ścieżką, usługą, modułem, stanem uwierzytelniania i oceną ryzyka
Twoi liderzy inżynieryjni widzą kształt Twojego interfejsu API bez konieczności otwierania ani jednego zgłoszenia.
Każdy punkt końcowy znaleziony przez Xygeni, wraz z jego metodą, stanem uwierzytelniania i oceną ryzyka, został zbudowany na podstawie kodu i specyfikacji.
Production note Wytnij panel AI Triage z dowolnego zrzutu ekranu API Security.
Zmapowano na 10 najlepszych rozwiązań bezpieczeństwa API OWASP
Wyniki odzwierciedlają ramy, z których korzystają już Twoje zespoły ds. bezpieczeństwa i audytorzy. Xygeni wykrywa ryzyko w całym obszarze bezpieczeństwa API OWASP. Pierwsza dziesiątka (10):
Jedna kategoria jest celowo pomijana. API6, czyli nieograniczony dostęp do poufnych przepływów biznesowych, wymaga zrozumienia, na co proces biznesowy ma pozwalać, a żaden analizator statyczny nie wykrywa tego wiarygodnie. Każdy dostawca, który twierdzi inaczej, sprzedaje Ci pole wyboru. To pole pozostaje w Twoim modelowaniu zagrożeń i testerach penetracyjnych.
Nie każde odkrycie jest takie samo: wrażliwość danych i toksyczne połączenia
Płaska lista ustaleń traktuje nieuwierzytelniony punkt końcowy kontroli stanu tak samo, jak nieuwierzytelniony punkt końcowy zwracający rekordy klientów. Nie są to te same problemy, a model priorytetyzacji, który ocenia je identycznie, uczy zespoły ignorowania listy.
Xygeni klasyfikuje dane obsługiwane przez każdy punkt końcowy, oznaczając PII, PCI i PHI w parametrach żądania i odpowiedziach, a następnie zestawia je ze stanem uwierzytelniania punktu końcowego.
Koreluje również wyniki, które trafiają do tego samego punktu końcowego i zwiększa ich wagę, gdy się kumulują. Wyciek danych osobowych w odpowiedzi jest sam w sobie poważnym odkryciem. Ten sam wyciek na punkcie końcowym, który nie wymaga uwierzytelnienia, jest krytyczny i platforma tak go ocenia, zamiast pozostawiać połączenie do ręcznego zauważenia przez kogoś innego.
Zombie i sieroty na punktach końcowych: dryf między kodem a specyfikacją
Ponieważ Xygeni czyta kod i specyfikację API równolegle, dostrzega różnice. Ten rozdźwięk ujawnia się w postaci trzech rozpoznawalnych wzorców:
- Nieudokumentowane punkty końcowe. Są zawarte w kodzie i nigdy nie zostały dodane do specyfikacji.
- Punkty końcowe zombie. Są one oznaczone jako przestarzałe lub wycofane i nadal można do nich uzyskać dostęp.
- Sieroce punkty końcowe. Nikt z obecnego zespołu nie jest ich właścicielem.
Żaden z nich nie pojawia się w inwentarzu dostępnym tylko dla specyfikacji, ponieważ to właśnie specyfikacja jest przyczyną ich braku.
Dowody, na podstawie których można działać, a nie mandat do wszczęcia śledztwa
Każde znalezisko wskazuje na konkretny odpowiedzialny program obsługi: plik, klasę, metodę i konkretny wiersz kodu, który wprowadził lukę, wraz z kodem powodującym błąd. Każde z nich ma również swoją wagę, kategorię OWASP API Security Top 10, swój CWE, stan uwierzytelnienia punktu końcowego oraz klasyfikację wrażliwości danych.
Odkrycie, które jedynie wskazuje punkt końcowy, zmusza programistę do przeszukiwania bazy kodu, zanim zdąży cokolwiek poprawić. Odkrycie, które wskazuje linię, pozwala mu natychmiast rozpocząć naprawę.
Wyniki eksportowane są w formatach JSON, CSV, Markdown i SARIF 2.1.0, dzięki czemu trafiają do tnarzędzia, w których Twoje zespoły już pracują.
Osoba obsługująca, linia i kod, który wprowadził ujawnienie. Nie jest to bilet do zbadania.
Dlaczego to działa na jednej platformie, a nie na innej konsoli
Xygeni zarządza API Security równolegle SAST, SCA, Tajemnice bezpieczeństwa, IaC oraz DZIEŃ w ramach jednej platformy, skorelowane poprzez ASPMzamiast wysyłać go jako osobne narzędzie z własnym login i własne zaległości.
Ma to znaczenie, ponieważ wyniki statyczne i wyniki w czasie wykonywania odpowiadają na różne pytania dotyczące tego samego punktu końcowego i są bardziej przydatne razem niż osobno. Wyniki statyczne informują o ryzyku związanym z punktem końcowym jeszcze przed jego uruchomieniem. DAST potwierdza, co jest faktycznie osiągalne i podatne na atak po uruchomieniu.
Podziel to na dwie konsole i skorelowane ryzyko tworzą dwa niezwiązane ze sobą backlogi. Nikt ich nie uzgadnia, a punkt końcowy, który jest zarówno nieudokumentowany, jak i nieuwierzytelniony, nie znajduje się w żadnej kolejce.
Zobacz prawdziwą powierzchnię ataku interfejsu API. Zabezpieczenia API są dostępne jako Enterprise dodatek do platformy Xygeni, a skanowanie zostanie przeprowadzone w obrębie Twojej własnej infrastruktury.
FAQ
Czy potrafi określić, które punkty końcowe przetwarzają poufne dane?
Tak. Xygeni oznacza PII, PCI i PHI w parametrach punktów końcowych i odpowiedziach, a następnie wykorzystuje tę klasyfikację do uporządkowania wyników według rzeczywistego narażenia.
Czy może działać na każdym pull request?
Tak. Skanowanie przyrostowe analizuje tylko te punkty końcowe, które uległy zmianie, a wygenerowany przez nie manifest może skupić kolejne skanowanie DAST na tych samych punktach końcowych, dzięki czemu testy statyczne i w czasie wykonywania są zgodne z tym, co faktycznie się zmieniło.
Czy mój kod opuszcza moje środowisko?
Nie. Skanowanie odbywa się w ramach Twojej własnej infrastruktury. Przesyłane są tylko wyniki, chronione w trakcie przesyłania i przechowywania.
Jak uzyskać API Security?
Zabezpieczenia API są dostępne jako Enterprise dodatek. Poproś o PoC, a my omówimy jego zakres.
