Czym różni się bezpieczeństwo API od ogólnego bezpieczeństwa aplikacji?

Chociaż czasami są mylone jako to samo, bezpieczeństwo aplikacji i bezpieczeństwo API to dwie odrębne dyscypliny. Bezpieczeństwo aplikacji odnosi się do zabezpieczania całych aplikacji, natomiast bezpieczeństwo API odnosi się do zabezpieczania interfejsów API używanych przez organizacje do łączenia aplikacji i wymiany danych. W związku z tym organizacje muszą przyjąć różne podejście do tych dwóch dyscyplin.

Co to jest bezpieczeństwo aplikacji?

Bezpieczeństwo aplikacji (AppSec) wykorzystuje praktyki autoryzacji, szyfrowania i bezpiecznego kodowania w celu ochrony danych i systemów przed cyberatakami. Organizacje wdrażające AppSec zmniejszają ryzyko naruszenia bezpieczeństwa danych, chronią dane wrażliwe i zapewniają zgodność swoich aplikacji ze standardami branżowymi.

ISACA definiuje pięć kluczowych komponentów programów AppSec jako:

1. Bezpieczeństwo według projektu
2. Bezpieczne testowanie kodu
3. Lista materiałów oprogramowania
4. Szkolenia i świadomość w zakresie bezpieczeństwa
5. Bramy zabezpieczeń WAF i API oraz opracowywanie reguł

Co to jest bezpieczeństwo API?

API, czyli interfejs programowania aplikacji, bezpieczeństwo chroni API przed atakami cybernetycznymi. W ostatnich latach nastąpił gwałtowny wzrost wykorzystania interfejsów API, zapewniając organizacjom możliwości wprowadzania innowacji poprzez umożliwienie przesyłania danych między aplikacjami. Niestety wraz ze wzrostem wykorzystania interfejsów API wzrasta liczba ataków na nie. Badania przeprowadzone przez Salt Security wykazały, że ataki na interfejsy API wzrosły o 400% między czerwcem a grudniem 2022 r.

Zagrożenia bezpieczeństwa aplikacji a API

Zrozumienie różnicy między zabezpieczeniami AppSec i API wymaga zrozumienia najważniejszych zagrożeń w każdej dyscyplinie. Na szczęście OWASP, organizacja non-profit zajmująca się poprawą bezpieczeństwa oprogramowania, udostępnia obszerną listę najważniejszych zagrożeń dla bezpieczeństwa aplikacji i bezpieczeństwa API. Listy, znane jako OWASP Top Ten, zbierają informacje od globalnej społeczności ekspertów ds. bezpieczeństwa OWASP w celu identyfikacji najbardziej krytycznych zagrożeń dla aplikacji i interfejsów API.

Co ciekawe, chociaż OWASP opublikował listę dziesięciu najważniejszych zagrożeń bezpieczeństwa aplikacji internetowych w 2003 r., listę dziesięciu najważniejszych zagrożeń bezpieczeństwa API opublikował dopiero pod koniec 2019 r. Ta rozbieżność stanowi kolejną kluczową różnicę między bezpieczeństwem aplikacji a bezpieczeństwem API: bezpieczeństwo aplikacji jest dobrze ugruntowanym, szeroko badana dyscyplina, która przeszła wiele etapów ewolucji, podczas gdy bezpieczeństwo API nie.

Chociaż nie mamy czasu na dogłębną analizę, warto pokrótce przyjrzeć się każdej liście, aby zobaczyć, czym się różnią, co powinno poinformować, w jaki sposób organizacje podchodzą do bezpieczeństwa AppSec i API.

Dziesięć najważniejszych zagrożeń bezpieczeństwa aplikacji OWASP (2021)

1. Uszkodzona kontrola dostępu — gdy nieautoryzowany użytkownik może uzyskać dostęp do zastrzeżonych informacji lub systemów
2. Awarie kryptograficzne – gdy strona trzecia ujawnia wrażliwe dane bez określonego zamiaru z powodu braku lub wad w kryptografii
3. Wstrzyknięcie – gdy atakujący próbuje wysłać dane do aplikacji w sposób, który zmieni znaczenie poleceń wysyłanych do interpretera
4. Niebezpieczny projekt – ryzyko związane z wadami architektonicznymi i projektowymi
5. Błędna konfiguracja zabezpieczeń — gdy zespoły ds. bezpieczeństwa błędnie konfigurują lub pozostawiają niepewne mechanizmy zabezpieczeń
6. Podatne na zagrożenia i nieaktualne komponenty – gdy organizacje pozostawiają komponenty bez poprawek
7. Błędy identyfikacji i uwierzytelniania (tzn. zerwane uwierzytelnianie) — gdy aplikacje są podatne na ataki uwierzytelniające
8. Awarie integralności oprogramowania i danych — gdy kod i infrastruktura nie chronią przed naruszeniami integralności
9. Awarie w zakresie rejestrowania i monitorowania bezpieczeństwa (tzn. niewystarczające rejestrowanie i monitorowanie) – gdy organizacje nie wykrywają naruszeń danych z powodu nieodpowiednich procedur rejestrowania i monitorowania
10. Fałszowanie żądań po stronie serwera — gdy napastnicy oszukują aplikacje, aby wysłały spreparowane żądanie do nieoczekiwanego miejsca docelowego, nawet jeśli są chronione zaporą sieciową, siecią VPN lub innym typem listy kontroli dostępu do sieci (ACL).

Dziesięć najważniejszych zagrożeń bezpieczeństwa API OWASP (2023)

1. Uszkodzona autoryzacja na poziomie obiektu – gdy obiekt API – na przykład bazy danych lub pliki – nie ma odpowiednich kontroli autoryzacji, co powoduje dostęp nieautoryzowanych użytkowników
2. Uszkodzone uwierzytelnianie – gdy inżynierowie oprogramowania i bezpieczeństwa źle rozumieją granice uwierzytelniania API i sposób jego wdrożenia
3. Autoryzacja na poziomie właściwości obiektu uszkodzonego – połączenie nadmiernego ujawnienia danych i masowego przypisania: gdy atakujący wykorzystują blokadę lub niewłaściwą autoryzację na poziomie właściwości obiektu.
4. Nieograniczone zużycie zasobów – zaspokojenie żądań API wymaga przepustowości sieci, procesora, pamięci i pamięci masowej. Dostawcy usług udostępniają inne zasoby, takie jak e-maile/SMS-y/rozmowy telefoniczne lub weryfikację biometryczną za pośrednictwem integracji API i opłacają je za każde żądanie. Skuteczne ataki mogą prowadzić do odmowy usługi lub zwiększenia kosztów operacyjnych.
5. Uszkodzona autoryzacja poziomu funkcji polega na tym, że osoby atakujące wysyłają uzasadnione wywołania interfejsu API do odsłoniętych punktów końcowych interfejsu API
6. Nieograniczony dostęp do wrażliwych przepływów biznesowych – interfejsy API podatne na to ryzyko ujawniają przepływ biznesowy – taki jak zakup biletu lub opublikowanie komentarza – bez kompensowania tego, w jaki sposób funkcjonalność może zaszkodzić firmie, jeśli będzie nadmiernie używana w sposób zautomatyzowany; niekoniecznie wynika to z błędów implementacyjnych.
7. Fałszerstwo żądania po stronie serwera — gdy interfejs API pobiera zdalny zasób bez sprawdzania poprawności identyfikatora URI dostarczonego przez użytkownika; umożliwienie osobie atakującej zmuszenia aplikacji do wysłania spreparowanego żądania do nieoczekiwanego miejsca docelowego, nawet jeśli jest chroniona przez zaporę sieciową lub VPN.
8. Błędna konfiguracja zabezpieczeń – interfejsy API i obsługujące je systemy zazwyczaj zawierają złożone konfiguracje, dzięki czemu można je lepiej dostosować. Inżynierowie oprogramowania i DevOps mogą przeoczyć te konfiguracje lub nie przestrzegać najlepszych praktyk bezpieczeństwa dotyczących konfiguracji, otwierając drzwi dla różnych typów ataków.
9. Niewłaściwe zarządzanie zapasami – interfejsy API udostępniają więcej punktów końcowych niż tradycyjne aplikacje internetowe, dlatego ważna jest właściwa i aktualna dokumentacja. Odpowiedni spis hostów i wdrożonych wersji interfejsu API jest również niezbędny do ograniczenia problemów, takich jak przestarzałe wersje interfejsu API i odsłonięte punkty końcowe debugowania.
10. Niebezpieczne korzystanie z interfejsów API – programiści mają tendencję do większego zaufania do danych otrzymanych z interfejsów API innych firm niż danych wprowadzanych przez użytkownika i przyjmują słabsze standardy bezpieczeństwa. Aby naruszyć bezpieczeństwo interfejsów API, napastnicy wykorzystują zintegrowane usługi stron trzecich, zamiast próbować bezpośrednio złamać docelowy interfejs API.

Jak widać, chociaż w pewnym stopniu te zagrożenia się pokrywają, aplikacje i interfejsy API są przede wszystkim narażone na różne, unikalne zagrożenia, na które organizacje muszą odpowiednio reagować. Kluczowa różnica między tymi dwiema listami polega na tym, że organizacje mogą ograniczyć wszystkie krytyczne ryzyka związane z bezpieczeństwem aplikacji za pomocą tradycyjnych, wielofunkcyjnych narzędzi i technik bezpieczeństwa, ale bezpieczeństwo API jest inne.

Bezpieczeństwo API to bardzo nowoczesny problem, który wymaga równie nowoczesnego rozwiązania. Organizacje nie mogą oczekiwać, że narzędzia, których używają do ochrony aplikacji i innych zasobów, spełnią zadanie polegające na zabezpieczeniu interfejsów API. Bezpieczeństwo API wymaga narzędzi bezpieczeństwa specyficznych dla API; tradycyjne metody ochrony, takie jak bramy API i zapory aplikacji internetowych (WAF), nie idą wystarczająco daleko.